[gold RFC] Do not generate dynamic reloc for unresolved TLS symbol
Cary Coutant
ccoutant@google.com
Thu Jan 29 04:33:00 GMT 2015
>> 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.
-cary
More information about the Binutils
mailing list