Re: [gold RFC] Do not generate dynamic reloc for unresolved TLS symbol

[Cary Coutant <ccoutant at google dot com>]

>> 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