Have you ever had a program crash before your
main Function carried out? it’s rare, but it can happen. If so, then you need to understand what goes behind the scenes between when the operating system starts your program and your first line of code in. happened
main executes. happily [Patrick Horgan] has a tutorial on the subject that is very detailed. It doesn’t cover statically linked libraries, but as he points out, once you understand what it is about you can easily figure this out for yourself.
It turns out that the operating system doesn’t know anything about main. However, it does know a symbol called _start. Your runtime library provides this. This code contains some stack manipulations and eventually calls
__libc_start_main which are also made available by the library.
From there, you’ll be presented with a few tricks to manage the program’s environment and other library calls, such as:
__libc_init still do some setup work. You’d think this would get you close, but there’s a lot more to do, including setting up for
at_exit and thunking for position-independent code, not to mention dynamically linked libraries.
This is one of the topics that you don’t seem to really need until you do. Even if you use a different language to generate executable files, you have to do all of these steps somewhere. Granted, for many languages the startup is static and it’s unlikely you will need to debug it, but it’s still good to know what’s going on under the hood.
If you want a quick Linux assembly tutorial, you’ve done it. If you prefer to shovel your assembly into a C source code file, you can too.