CppCon 2018: Matt Godbolt “The Bits Between the Bits: How We Get to main()”
Why Stack Overflow recommends it
Stack Overflow users link it when explaining how executables are linked, loaded and started, including static initialization before main(), dynamic linking and duplicate symbols across shared libraries.
Recommended by 9 people across 12 different months, 2019 to 2025.
What it is
A CppCon 2018 talk by Matt Godbolt, creator of Compiler Explorer, on what happens between launching a Linux program and reaching main(). It covers how the linker combines object files, dynamic linking and the loader, ODR violations, and C and C++ runtime startup including global constructors.
What people said
Strong rec gstukelj · 2019-09 · Stack Overflow · on “Why does compiling a C program produce such a long binary?”
This is likely due to some #include statements that statically bind libraries with your executable, or a compiler and a linker including debugging information. Of course an executable also contains a lot of OS specific data/information which add up to the size, see this question [LINK] for more detailed answers. If you're after a small size executable there's plenty of suggestions in the answers to this question [LINK] . EDIT: Reading more about it, the size comes down to C being a high-level language in the sense that it does not communicate directly with hardware, but rather talks with an operation system. Basically, main is not the entry point [LINK] of your program and there's a lot that
Strong rec Jeremy Friesner · 2021-12 · Stack Overflow · on “How does main() receive command line arguments?”
Matt Goldbolt gives a really interesting presentation on the subject of process setup in Linux, here: [this video]
Recommends Alecto · 2019-03 · Stack Overflow · on “What actually happens when two shared libraries define the same symbol?”
Part 1: About the Linker This is a known problem in both C and C++, and it's the result of the current compilation model. A full explanation of how it happens is beyond the scope of this answer, however this talk by Matt Godbolt [this video] provides an in-depth explanation of the process for beginners. See also this article on the linker [LINK] . There's a new version of C++ coming out in 2020, and it'll introduce a new compilation model (called Modules) that avoids problems like this. You'll be able to import and export stuff from a module, similar to the way packages work in Java. Part 2: Solving your problem There are a few different solutions. Magical Solution 1: One unique global variable T
Recommends metal · 2019-04 · Stack Overflow · on “Why does Visual Studio Code catch an exception in the very beginning of my main?”
Update : As @rustyx noted in the comments, the sort of problem I describe here probably would not produce the symptom in the OP because the program does continue. Most likely it is a problem in the toolchain / inter-device debugging. I'd suggest trying GDB by itself and see if you get the same results or more info. This can happen if you have initialized some global or static variable before main() , and that initialization causes an exception. See Matt Godbolt's talk at CppCon 2018 " The Bits Between the Bits: How We Get to main() [this video] ". Consider this: int main() {} // Initialized before main static const auto x = []( auto i ) { if( i == 0 ) throw; return i; }( 0 );
Recommends Max Langhof · 2019-08 · Stack Overflow · on “debugging assignments to global variables before main”
I recommend this talk by Matt Godbolt: [this video] (slides here [LINK] ) - it gives you the background info to understand how this initialization is done behind the scenes and where you can thus intercept it. In your example, you can see [LINK] that gcc outputs a function that the linker is supposed to call before `main`: `_GLOBAL__sub_I__Z1fv`
Recommends IInspectable · 2020-04 · Stack Overflow · on “Where is WinMain() in Win32 API implemented?”
The documentation for WinMain [LINK] explains, what it is: The user-provided entry point for a graphical Windows-based application. It is declared in the SDK, but the program author is required to implement it. When a new process is created, the OS calls into the executable image's exported entry point. By default, this is the C Runtime's (CRT) entry point ( WinMainCRTStartup [LINK] ), that prepares the execution environment prior to transferring control to the user-provided entry point WinMain . This is the first user-authored code that executes. You can find more information on what is going on when when launching an executable on Windows at WinMain is just the conventional name for the Wi
Recommends Marek R · 2020-06 · Stack Overflow · on “What is this weird machine code at the beginning of my C++ program and how do I remove it”
I think you will find explanation here [this video] . Basically this code will call resolve function placed in dynamic library.
Recommends Marek R · 2022-01 · Stack Overflow · on “Shared library with statically linked dependencies”
No. Then library first have to be build as static to work like this. In your case you have shared library which was linked dynamically. So lib*.so file is loaded lazily behind scene. Here is nice explanation how this works: [this video]
Recommends Pepijn Kramer · 2022-06 · Stack Overflow · on “Cross-platform binary in C++”
If you want to now a bit more about what a Compiler/Linker/OS does to get an executable to run watch this video from Mat Godbolt (the guy from compiler explorer) : The bits between the bits [this video] . There is more to it then you think
Recommends Marek R · 2023-12 · Stack Overflow · on “Wrap a function without changing the call sites?”
Not sure this is current link (do not have time to watch this again), but take a look on this: [this video] but quick scanning I think this is proper talk.