[PATCH] Reduce the statically linked startup code [BZ #23323]
Florian Weimer
fweimer@redhat.com
Mon Mar 1 09:43:40 GMT 2021
* Mike Frysinger:
>> What about this?
>>
>> /* Note: This file is part of the startup code in statically linked
>> programs. From the statically linked startup code, dynamically
>> linked programs call __libc_start_main in libc.so, which is compiled
>> from this file as well, but not part of the statically linked startup
>> code due to this separation. */
>
> iiuc, libc-start ends up in libc.a & libc.so. in both cases, it provides
> the __libc_start_main symbol, and in both cases, the crt object calls it.
>
> when you say "statically linked startup code", i'm guessing you're referring
> to the crt objects.
>
> so when you say "part of the startup code in statically linked programs", it
> makes it sound like this file is not used in shared programs which is not the
> case at all.
>
> how about:
> /* This file provides __libc_start_main which is responsible for initializing
> the glibc runtime before transferring execution to the main function. It is
> called from the startup code statically linked into all programs (e.g. the
> crt1.o object that provides the _start symbol).
>
> In a statically linked program, it is linked directly into the image via the
> libc.a archive. In a dynamically linked program, it is part of libc.so. */
> -mike
By being part of the startup code, I meant code that runs very early,
before full platform initialization (like the TCB). In the statically
linked base, __libc_start_main is in that category. But in the
dynamically linked case, it runs very late (after ELF constructors for
the initially loaded DSOs, for example). This is an important
distinction, I think.
We can argue about this some more, or split the file in two. 8-)
Thanks,
Florian
More information about the Libc-alpha
mailing list