3 ms·

It says _start (crt0.o) comes from libc. But note, if you run nm on a binary you can see _start is part of the binary, not libc.so.

naniwaduni 4y ago
The "libc" is more than libc.so. Your system headers, for example, must be shipped with your libc, even though everything that would change if you replace them with something nonsensical would be in "your" binary, not in libc.so. libc functions don't stop coming from the libc if you statically link them. A C runtime is often provided by the same project as the C standard library (the other viable option is to have it provided by the compiler project).
- asveikau 4y ago
  > Your system headers, for example, must be shipped with your libc, Not all. Typically stdarg.h is not. On Linux, <sys/*> is not.
mbeddedartistry 4y ago
It says "usually". It varies! But, in general, the libc implementations I have looked at handle this. This includes Newlib, glibc (they call it start.s), picolibc, musl (crt1), and my own libc. The presence in your binary only means that crt0.o was statically linked (may be an expectation of the loader on your system). If you linked against a static libc, you would also see those symbols as part of the binary.
- asveikau 4y ago
  I think your last paragraph is wrong. crt0.o is static even when linking to libc.so dynamically. The ELF format has something in the headers for an entry point which will point at _start in your own binary, not in libc.so. I'm pretty sure it works that way on windows too, but they call the symbol mainCRTStartup or some such.
  - mbeddedartistry 4y ago
    What, exactly, is wrong? The point I am making is that crt0.o usually comes from libc, even if it is linked separately. I suspect that the loader expects the ELF entry point to be an address in the application, not a dynamically linked library, which is why crt0.o must be statically linked.

naniwaduni 4y ago

The "libc" is more than libc.so. Your system headers, for example, must be shipped with your libc, even though everything that would change if you replace them with something nonsensical would be in "your" binary, not in libc.so. libc functions don't stop coming from the libc if you statically link them. A C runtime is often provided by the same project as the C standard library (the other viable option is to have it provided by the compiler project).

asveikau 4y ago
> Your system headers, for example, must be shipped with your libc, Not all. Typically stdarg.h is not. On Linux, <sys/*> is not.

mbeddedartistry 4y ago

It says "usually". It varies! But, in general, the libc implementations I have looked at handle this. This includes Newlib, glibc (they call it start.s), picolibc, musl (crt1), and my own libc. The presence in your binary only means that crt0.o was statically linked (may be an expectation of the loader on your system). If you linked against a static libc, you would also see those symbols as part of the binary.

asveikau 4y ago
I think your last paragraph is wrong. crt0.o is static even when linking to libc.so dynamically. The ELF format has something in the headers for an entry point which will point at _start in your own binary, not in libc.so. I'm pretty sure it works that way on windows too, but they call the symbol mainCRTStartup or some such.
- mbeddedartistry 4y ago
  What, exactly, is wrong? The point I am making is that crt0.o usually comes from libc, even if it is linked separately. I suspect that the loader expects the ELF entry point to be an address in the application, not a dynamically linked library, which is why crt0.o must be statically linked.