[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