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: Jiong Wang <jiong dot wang at foss dot arm dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>, Michael Matz <matz at suse dot de>, Cary Coutant <ccoutant at gmail dot com>, Binutils <binutils at sourceware dot org>
- Date: Wed, 2 Mar 2016 13:24:18 +0000
- 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 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> <CAJimCsG=1u_yM6SBFAxCxB4JvWtxO5fZ22+OmG6UC_RYON3DdA at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602251356320 dot 20277 at wotan dot suse dot de> <CAMe9rOpzw08UPTfjFEhixY=x4je--03ZdsXdrpdS-2sYSxDE3Q at mail dot gmail dot com> <56D5A0D9 dot 5070500 at foss dot arm dot com> <CAMe9rOq_sXd9qccTddvMB8sTBgOPWq0wgiqSQX4iSyUVys4n-Q at mail dot gmail dot com> <56D6D676 dot 5020202 at foss dot arm dot com> <CAMe9rOq__U54POpvUgKrYTinD1J0josM6MWph3d+zGmm=v3rgQ at mail dot gmail dot com> <56D6DC51 dot 8040503 at foss dot a rm.com> <CAMe9rOq_LZTeC+Zkd6L-o=8Sd=hbvmTDJ+LOCMXfqVAuyU+5CQ at mail dot gmail dot com>
On 02/03/16 12:50, H.J. Lu wrote:
On Wed, Mar 2, 2016 at 4:28 AM, Jiong Wang <firstname.lastname@example.org> wrote:
On 02/03/16 12:22, H.J. Lu wrote:
On Wed, Mar 2, 2016 at 4:03 AM, Jiong Wang <email@example.com>
On 01/03/16 14:37, H.J. Lu wrote:
On Tue, Mar 1, 2016 at 6:02 AM, Kyrill Tkachov
On 26/02/16 12:51, H.J. Lu wrote:
On Thu, Feb 25, 2016 at 10:59 AM, H.J. Lu <firstname.lastname@example.org> wrote:
Here is the updated patch I am testing. The linker behavior is
in 2 cases when creating executable:
1. When there are mixed PIC and non-PIC references to undefined
weak symbols, undefined weak symbols are resolved to 0 at link-time.
2. If all references to undefined weak symbols are PIC, dynamic
relocations against undefined weak symbols will be generated unless
-z nodynamic-undefined-weak is passed to linker.
BTW, We have to resolve R_X86_64_32/R_X86_64_PC32 relocations
against undefined weak symbols to zero. Otherwise, we will get
relocation overflow for dynamic R_X86_64_32/R_X86_64_PC32
This is what I am checking in.
NA->FAIL: Mixing PIC and non-PIC
You can either fix aarch64 backend or skip the test for aarch64.
For your testcase, AArch64 is not generating dynamic relocation for
weak undefined symbol referenced from non-pic code when linking
exectuable, instead, it's resolved to zero during static linking
As far as I know, this behavior is exactly what's described here at
And reading those historical discussions,
Looks to me the ld behavior changes introduced by your patch is quite
sensitive and there still be lack of consensus.
What linker change were you referring to? I only added a testcase.
I mean those linker changes added together with this testcase.
Author: H.J. Lu <email@example.com>
Date: Fri Feb 26 04:16:15 2016 -0800
[x86] Resolve non-PIC undefweak symbols in executable
As far as aarch64 backend is concerned, I only added a testcase.
Well, then why you put it under generic directory? and without
on x86? this is implicitly affect all targets, and enforcing all targets
the changes on x86. I think similar changes should only be encouraged
to other target
if it's conventional rules, or it's clearly documented by generic or
that target's ELF
While reading from http://www.skyfree.org/linux/references/ELF_Format.pdf,
"The link editor does not extract archive members to resolve undefined
weak symbols. Unresolved weak symbols have a zero value."
Looks to me the spec is even more strict that weak symbol's life is
defined to be ended
after static linking stage. All unresolved weak symbols are assigned
IMO, the support of weak symbol under various rare and complex scenarios
target specific, thus I'd either move this testcase under x86 directory
or put it under
generic directory but enabling it on x86 only initially. If other
targets want and start
to support similar features like x86 on weak symbol, then they can be
This looks to me is a more clean & acceptable way to other targets.