[PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
Cary Coutant
ccoutant@gmail.com
Wed Feb 24 23:08:00 GMT 2016
More information about the Binutils mailing list
Wed Feb 24 23:08:00 GMT 2016
- Previous message (by thread): [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
- Next message (by thread): [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message (by thread): [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
- Next message (by thread): [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list