This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
- From: Cary Coutant <ccoutant at gmail dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Binutils <binutils at sourceware dot org>
- Date: Wed, 24 Feb 2016 15:08:50 -0800
- Subject: Re: [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
- Authentication-results: sourceware.org; auth=none
- References: <20160223175814 dot GA2858 at intel dot com> <alpine dot LSU dot 2 dot 20 dot 1602241541430 dot 20277 at wotan dot suse dot de> <CAMe9rOoxU43=dhGYZZGQtWhfbU-sGRoaiiJ7PfPNtzSc05-t-A at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241552020 dot 20277 at wotan dot suse dot de> <CAMe9rOpEWKVVP=-o0t0emkjKR0-xqnn-YZ5C5nfa=0E4BkEZaw at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241709410 dot 20277 at wotan dot suse dot de> <CAMe9rOr5qa_PBJA3oDENWErRfrojtzC1ncXaWwyh-1EAczPn-g at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241749340 dot 20277 at wotan dot suse dot de> <CAMe9rOrSNYV_x-5aU7K+hXHNrinE9Co8y1F5VUkY+SoRQize=g at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241753490 dot 20277 at wotan dot suse dot de> <CAMe9rOpZNHtKRvx+5QurEOcVU96WEQuBRPJ6UorocjE-8Jd+vQ at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241808400 dot 20277 at wotan dot suse dot de> <CAMe9rOpAkC238Gvji0rf1_wBqEAZDDeTkhp_o-BirUrTa622aA at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241843180 dot 20277 at wotan dot suse dot de>
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 <email@example.com> wrote:
> 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
> And this even supports my view, it specifically talks about changes in the
> runtime environment, which wouldn't matter if the link editor resolved
>> 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.