3 ms·

The author states: >"The linker is still adding an interface to the OS for us, and it is that interface that actually calls main(). So how do we get around tha

The author states: >"The linker is still adding an interface to the OS for us, and it is that interface that actually calls main(). So how do we get around that if we don't need it?" Is the author stating that _start is an interface to the OS then? It's interesting I never thought of this as being an interface. Is this an interface because _start actually sets up the stack used to pass argc, argv and the environment variables? I believe _start is found in the C runtime crt.o correct? The author then states: >"The actual entry point that the linker uses by default is the symbol with the name _start. When we link with gcc, it automatically includes a _start routine, one that sets up argc and argv, among other things, and then calls main()." Is this just a long-winded way of saying _start sets up the stack for the new process? WIthout a stack you can't "set up" argc, argv etc. I would also be curious what "among other things" might include.

saagarjha 7y ago
You may find glibc's implementation of _start interesting: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/start.S https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86...
breadbox 7y ago
> Is the author stating that _start is an interface to the OS then? It's interesting I never thought of this as being an interface. Perhaps it's not the best term, but it's not really incorrect. I probably wouldn't phrase it that way today (20 years later). > Is this just a long-winded way of saying _start sets up the stack for the new process? WIthout a stack you can't "set up" argc, argv etc. Well -- to be precise, the stack is created by the kernel during the exec system call. The kernel also copies the argument and environment strings into the process's memory. However, the kernel does not create the argv array of pointers, or the envp array. Building those arrays is the job of _start(), and that is what I meant by "setting up argc and argv". Please note: That was the case back in 1999. Things are different now -- I think it changed with the 64-bit kernel? In any case, nowadays the ELF loader in the kernel also builds the arrays. > I would also be curious what "among other things" might include. As before, it depends on the C runtime. The _start() function might ensure proper initialization of libc, for example. (Again, with current binaries that's usually done via an `.init` section, but in 1999 that was not the norm.)

saagarjha 7y ago

You may find glibc's implementation of _start interesting: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/start.S https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86...

breadbox 7y ago

> Is the author stating that _start is an interface to the OS then? It's interesting I never thought of this as being an interface. Perhaps it's not the best term, but it's not really incorrect. I probably wouldn't phrase it that way today (20 years later). > Is this just a long-winded way of saying _start sets up the stack for the new process? WIthout a stack you can't "set up" argc, argv etc. Well -- to be precise, the stack is created by the kernel during the exec system call. The kernel also copies the argument and environment strings into the process's memory. However, the kernel does not create the argv array of pointers, or the envp array. Building those arrays is the job of _start(), and that is what I meant by "setting up argc and argv". Please note: That was the case back in 1999. Things are different now -- I think it changed with the 64-bit kernel? In any case, nowadays the ELF loader in the kernel also builds the arrays. > I would also be curious what "among other things" might include. As before, it depends on the C runtime. The _start() function might ensure proper initialization of libc, for example. (Again, with current binaries that's usually done via an `.init` section, but in 1999 that was not the norm.)