This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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.


On Wed, Feb 24, 2016 at 9:50 AM, Michael Matz <> 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 at run-time do want to use vale 0 for
>> unresolved weak symbols.  We used to treat STB_WEAK differently in
>> 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
> to handle, so the fact that it does handle them also indicates that
> ld should not.
> Ciao,
> Michael.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]