[PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
H.J. Lu
hjl.tools@gmail.com
Wed Feb 24 23:20:00 GMT 2016
More information about the Binutils mailing list
Wed Feb 24 23:20: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 ]
On Wed, Feb 24, 2016 at 3:08 PM, Cary Coutant <ccoutant@gmail.com> wrote: > 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. > Generate a dynamic relocation against undefined weak symbol isn't an option for x86-64 if input isn't PIC due to run-time relocation overflow in .text section. -- H.J.
- 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