Re: Linking musl with ld.gold

[Rich Felker <dalias@libc.org>]

On Thu, May 08, 2014 at 03:08:41AM +0100, Stephen Thomas wrote:
> > On Wed, May 07, 2014 at 01:04:43PM +0300, Timo Teras wrote:
> > > On Wed, 7 May 2014 10:04:24 +0100
> > > Stephen Thomas <scjthm@live.com> wrote:
> > > 
> > > > > only the object files with referenced symbols are linked from an
> > > > > archive
> > > > > 
> > > > > so only a.o with the given main.o because of the symbol f
> > > > > 
> > > > > now if you make some reference in main.c such that b.o should
> > > > > be included but main still returns 0 that would be a bug
> > > > > 
> > > > > eg. add a void g(void){} to b.c and call it from main.c  
> > > > 
> > > > Ok, thanks for that info. It appears that there is a problem in gcc
> > > > 4.9 and not 4.8.3.
> > > 
> > > 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.
> 
> I will raise an issue with the gcc team (but I don't really want to
> build from git, as it takes too long). I am not saying that the
> library doesn't work, I am merely saying that there was a bug where
> stdout was not being flushed, and this in my opinion was due to the
> weak symbol in fflush not being overridden. I did run that single
> test case on the two different builds and the result was different.
> This was on two clean buildroot branches based on uclibc.

My reply to Timo was not in doubt that you observed such an issue, but
rather expressing doubt about his possible explanation. I don't think
it has anything to do with -ffunction-sections or -fdata-sections.

> I don't understand what you mean by garbage collection. Basically,

Those two options are meant to be used with the linker option
--gc-sections, which performs garbage collection to remove any
sections which are not referenced.

> if I understand this correctly, there is a weak symbol defined in
> fflush.c for the purpose of allowing this file to run without the an
> implementation that initialises the real symbol with the internal
> implementation of stdout (which is just basically a manufactured
> wrapper around file descriptor number 1). This is good as far as
> unit testing goes, doesn't use #defines but the linker -- good
> stuff. However, when I noticed was that the prompt on busybox using
> musl was not appearing until after a new line was entered, I added a
> discovered that the value of the pointer was 0 (NULL). If you still
> suspect that my claim is wrong, then I believe you are saying that

I'm just saying Timo's claim about the mechanism of what you observed
is probably wrong. The way the 'magic' with weak symbols work is that
the weak definition satisfies the reference, so that the linker does
not need to pull in additional object files to satisfy it. But once an
additional file which has a strong definition is pulled in (as a
result of another undefined symbol reference), the strong definition
is _referenced_ (because it overrides any weak definitions) and thus
its section is not a legal candidate for garbage collection via
--gc-sections.

> this is not the case. It would be nice if someone who has gcc 4.9
> installed could run either run the test or check that busybox is
> working.

The bug is almost surely in the linker, not gcc, unless it's a matter
of gcc passing bad options to the linker. You can add -v to the gcc
command line for linking to see exactly how it invokes the linker.

Rich