The Linux X86 journey to the principal ()

0


Have you ever had a program crash before your main does the function run? it’s rare, but it can happen. When this is the case, you need to understand what goes behind the scenes between when the operating system starts your program and your first line of code in main executed. Fortunately [Patrick Horgan] To a tutorial on the subject it’s very detailed. It doesn’t cover statically linked libraries but, as he points out, if you understand what it covers, it’s easy to figure out for yourself.

Turns out the operating system doesn’t know anything about main. It does, however, know a symbol called _start. Your runtime library provides this. This code contains a stack manipulation and ultimately calls __libc_start_main which is also provided by the library.

From there, you end up with a few tips for handling the program environment and more library calls such as __libc_init_first and __libc_init do a little more setup work. You’d think it would bring you closer together, but there’s a lot more to do, including setting up for at_exit and think about position independent code, let alone dynamically linked libraries.

This is one of those topics that you won’t really need until you do. Even if you are using another language to generate executables, they all need to follow these steps somewhere. Granted, for many languages ​​startup is static and you’re unlikely to debug it, but it’s always good to know what’s going on under the hood.

If you want a quick Linux assembly tutorial, go ahead. If you prefer to shovel your assembly into a C source code file, you can do that as well.


Share.

Leave A Reply