Linux x86 program start up – How the heck do we get to main()? (2011)
Great article, it was immensely useful in my quest to understand Linux processes. It says "Linux x86 program" but it assumes it's a hosted C program whose entry point is provided by GCC startfiles and libc. Everything after _start is specific to C. Note that _start is an arbitrary symbol and merely the linker's default value of the entry point. It can be changed to anything.<p>The important Linux facts are:<p>1. _start is not a function<p>It can't be returned from, the exit system call must be issued before execution terminates.<p>2. Arguments and environment are on the stack<p>Argument count and vector can be simply popped off the stack into appropriate registers, in that order.<p>The environment vector is located after the NULL terminator of the argument vector, or argument count + 1.<p>The auxiliary vector is located after the NULL terminator of the environment vector. No count is provided for that, so code must loop through the environment looking for the sentinel in order to find it.<p>The auxiliary vector is really interesting. I don't usually see software making direct use of it. It contains interesting information such as CPU identifier and capabilities, page size, the location of the Linux vDSO, some random bytes, program file name, user and group IDs, among other things.<p><a href="https://github.com/torvalds/linux/blob/master/include/uapi/linux/auxvec.h" rel="nofollow">https://github.com/torvalds/linux/blob/master/include/uapi/l...</a><p><a href="https://github.com/torvalds/linux/blob/master/arch/x86/include/uapi/asm/auxvec.h" rel="nofollow">https://github.com/torvalds/linux/blob/master/arch/x86/inclu...</a><p><a href="https://github.com/torvalds/linux/blob/master/Documentation/ABI/stable/vdso" rel="nofollow">https://github.com/torvalds/linux/blob/master/Documentation/...</a><p>This is the data the Linux kernel passes to programs. After organizing these parameters, the program is free to do whatever it wants. The libc entry point will naturally start setting up libc. In particular, it seems to spend a lot of time setting up the init and fini insanity that's probably better off forgotten.<p><a href="https://blogs.oracle.com/solaris/post/init-and-fini-processing-who-designed-this" rel="nofollow">https://blogs.oracle.com/solaris/post/init-and-fini-processi...</a><p>It's not necessary. After this, you can just run your program directly. I used to develop a liblinux that illustrates all this with much simpler code:<p><a href="https://github.com/matheusmoreira/liblinux/blob/master/start/x86_64/_start.S" rel="nofollow">https://github.com/matheusmoreira/liblinux/blob/master/start...</a><p><a href="https://github.com/matheusmoreira/liblinux/blob/master/start/x86_64/liblinux_start.c" rel="nofollow">https://github.com/matheusmoreira/liblinux/blob/master/start...</a><p>The entry point code passes the stack pointer to a C function which gathers all kernel parameters and starts the program with no further setup. I made several example programs, including one which outputs all these variables.<p><a href="https://github.com/matheusmoreira/liblinux/blob/master/examples/environment.c" rel="nofollow">https://github.com/matheusmoreira/liblinux/blob/master/examp...</a><p>I stopped developing this because I discovered the Linux itself has a better solution that they use for their own tools:<p><a href="https://github.com/torvalds/linux/blob/master/tools/include/nolibc/nolibc.h" rel="nofollow">https://github.com/torvalds/linux/blob/master/tools/include/...</a><p>The entry point code for all supported architectures is present as inline assembly code!