This is the mail archive of the
mailing list for the binutils project.
Re: [gold RFC] Do not generate dynamic reloc for unresolved TLS symbol
- From: Cary Coutant <ccoutant at google dot com>
- To: Cary Coutant <ccoutant at google dot com>, Binutils <binutils at sourceware dot org>, Ian Lance Taylor <iant at google dot com>, Jing Yu <jingyu at google dot com>, Han Shen <shenhan at google dot com>, Doug Kwan <dougkwan at google dot com>, David Miller <davem at davemloft dot net>
- Date: Wed, 28 Jan 2015 20:33:26 -0800
- Subject: Re: [gold RFC] Do not generate dynamic reloc for unresolved TLS symbol
- Authentication-results: sourceware.org; auth=none
- References: <CAHACq4oi4UT7LLv-vz5+ocpkPU8zwtyOQ8Gas_S3WdB_7WgN2w at mail dot gmail dot com> <20141218224458 dot GC31055 at bubble dot grove dot modra dot org> <CAHACq4q3UBVdhiXzeT6e2H0t-c_DA926C9s61+-YAsYzmyTs2g at mail dot gmail dot com> <CAHACq4r2tZ9g=uSH+PEDovrUdy4FHFVYmeZXxYiPQvqapdCzJw at mail dot gmail dot com> <20150129032140 dot GE12931 at bubble dot grove dot modra dot org>
>> created. This patch allows the IE-to-LE optimization for an undefined symbol
>> when building an executable,
> Thinking out loud here. That looks like a contradiction to me. If
> the symbol is undefined, how can it be local-exec?
If it's undefined in an executable (and the reference isn't PIC), then
we statically resolve it to zero. That means it can be local-exec.
> Oh, is this the undefined weak case? Hmm, seems to me that undefined
> weaks don't play well with TLS symbols.. Even for initial-exec you
> won't have its address resolve to zero as you do with non-TLS symbols,
> because tp is always added. So
> if (foo)
> /* Do something when foo is defined. */
> will "Do something" even when foo is undefined.
Yes, for TLS symbols, resolving to zero doesn't *really* resolve to
zero. We just resolve to TP+0 because that's the best we can do (it's
what BFD ld does).
The particular bug I'm responding to isn't a weak undefined -- it's a
normal undefined, linked with --warn-unresolved-symbols, and the code
containing the reference won't get executed (it's an artifact from
gcc's lightweight IPO implementation). In that case, gold was creating
a dynamic relocation, which caused an unsatisfied symbol error from
the dynamic loader. In addition, in a small test case with no other
TLS symbols, it caused gold to assert because we expect a TLS segment
when applying the relocation.