Re: gold linker 2.22 regressed for DragonFly [revised testsuite results]

[Ian Lance Taylor <iant@google.com>]

John Marino <dragonflybsd@marino.st> writes:

>>> Ideally rtld should not have a publically visible definition of
>>> __bss_start, but I don't see how it would cause a test failure even if
>>> it did.
>
>
> After many hours of digging into the issue, I might have an
> explanation for why the __bss_start and _edata symbols are getting
> assigned to the dynamic symbol table.  This is the only test that
> FreeBSD passes and DragonFly doesn't, and the reason for that wasn't
> clear.
>
> Finally using --trace-symbol=__bss_start might have provided a clue.
> It said __bss_start was defined in libc.so, libm.so, and libstdc++.so.
> My guess is that the presence of the symbols in those libraries caused
> gold to promote the __bss_start symbol to global.
>
> As for why FreeBSD doesn't have these symbols in their system
> libraries, the difference might be in their use of symbol version
> maps. Unfortunately DragonFly doesn't yet version their library
> functions, so the lack of version scripts means every library has this
> symbol.
>
> Am I on the right track in diagnosing this test failure?

Sounds like it.  There may be a target independent problem here. What
should the linker do if the version script specifies that a symbol is
local but the symbol is also defined in a shared library?  I think it
has to make the symbol local despite the definitions, but it sounds like
that is not happening.


> I came up with an initial implementation of relro for the dynamic
> linker and FreeBSD's Konstantin Belousov reviewed and added to it.
> Now DragonFly passes these three tests and I think there's a good
> chance that code will get incorporated into FreeBSD as well.

Cool.

Ian