[PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable

[Cary Coutant]

FWIW, gold used to leave references to weak undefs for the dynamic
loader to resolve. We got complaints, and changed it to match gnu ld's
behavior:

https://sourceware.org/ml/binutils/2008-04/msg00019.html

https://sourceware.org/ml/binutils/2008-04/msg00269.html

I'd prefer not to change ld after having already changed gold to match
-- especially so when that change was motivated by user complaints.

Daniel replied to the first of the above messages, suggesting that the
existing ld behavior was surprising, and I agreed. Ian's response was:

> Based on this discussion, I think we should go ahead and commit this
> to gold.  It makes gold act like GNU ld.  Clearly more thought is
> required before changing the linker behaviour in this area.

I suppose this thread can be considered "more thought", but it hasn't
swayed me. We've had eight more years worth of installed base using
the current behavior since that discussion.

-cary


On Wed, Feb 24, 2016 at 9:50 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Wed, 24 Feb 2016, H.J. Lu wrote:
>
>> > Can you cite something to support this statement?  Is everyone here of
>> > this opinion?
>> >
>>
>> Weak symbol was introduced for system libraries.  gABI has "Unresolved
>> weak symbols have a zero value."
>
> Sure, in the paragraph talking about archive members.  Ripping it out of
> context can also mean "Unresolved at runtime".
>
>> The behavior of weak symbols in areas not specified by this document
>> is implementation defined. Weak symbols are intended primarily for use
>> in system software. Applications using weak symbols are unreliable
>> since changes in the runtime environment might cause the execution to
>> fail.
>
> And this even supports my view, it specifically talks about changes in the
> runtime environment, which wouldn't matter if the link editor resolved
> everything.
>
>> Ld at link-time and ld.so at run-time do want to use vale 0 for
>> unresolved weak symbols.  We used to treat STB_WEAK differently in ld.so
>> and later changed to treat STB_WEAK the same as STB_GLOBAL for defined
>> symbols, i.e. there are no weak defined symbols at run-time.
>
> That makes sort of sense even, but I'm talking about _references_ to weak
> symbols.  If ld resolved undef-weaks, then there would be nothing left for
> ld.so to handle, so the fact that it does handle them also indicates that
> ld should not.
>
>
> Ciao,
> Michael.