Re: Linking musl with ld.gold

[Rich Felker <dalias@libc.org>]

On Thu, May 08, 2014 at 08:11:26AM +0300, Timo Teras wrote:
> On Wed, 7 May 2014 21:06:05 -0400
> Rich Felker <dalias@libc.org> wrote:
> 
> > On Wed, May 07, 2014 at 01:04:43PM +0300, Timo Teras wrote:
> > > Is perhaps -ffunction-sections and/or -fdata-sections added
> > > automatically? Those would break musl like experienced.
> > 
> > They should not break musl; if they do, it's a compiler bug. The
> > strong symbol that overrides the weak symbol elsewhere is not unused
> > and available for garbage collection because it's referenced.
> > 
> > I suspect your claim is just wrong, since IIRC people have
> > successfully used these options with musl.
> 
> -fdata-sections breaks things to my understanding.
> 
> stdin.c (and others), have:
> 
> FILE *const stdin = &f;
> FILE *const __stdin_used = &f;
> 
> And __stdin_used is only ever referenced via weak alias. -fdata-section
> makes each symbol go to different section, and if linker has
> gc-sections, it'll remove any unreferenced section. This means

But the section is not unreferenced. There's a reference to
__stdin_used from __stdio_exit.o. Ignoring this reference just because
it could have been satisfied by a weak symbol is wrong.

> __stdin_used will never get pulled in causing problems like described
> in the original mail.

I don't see anywhere it's documented to behave this way, and in fact
making it behave this way would not only be harmful but more difficult
than making it behave correctly. The basic way a linker works is to
pull in all objects to satisfy undefined symbols; performing GC on
sections is a separate task that takes place (or at least should)
after all symbols have been resolved, and thus once it's possible to
know which symbols are referenced and which are not.

Rich