[llvm-bugs] [Bug 40570] lld ignores addend for weak undefined TLS symbol in static executable

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=40570

Fangrui Song <i at maskray.me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
                 CC|                            |i at maskray.me

--- Comment #3 from Fangrui Song <i at maskray.me> ---
gABI says "Unresolved weak symbols have a zero value."
But I think this doesn't apply to TLS symbols. These local-exec TLS relocations
resolve to offsets relative to TP. To make the value 0, you have to resolve the
relocation to the negative TP, plus some offset, this is simply impossible. I
agree with Peter that the value of "undefined weak TLS symbol" is implemented
defined.

Another problem is that PT_TLS may not exist (not defined or discarded), but
their computation may rely on p_memsz/p_align of PT_TLS. I don't know how to
interpret such offsets.

Returning r_addend instead of 0 makes sense. In some cases (e.g.
R_X86_64_TPOFF32), the compiler may be smart enough to fold immediate offset
into the relocation. Ignoring r_addend may break the computation of &a[3]-&a[0]
(this is brittle anyway, but `0` -> `A` is a change that doesn't change the
file size :)

This issue did motivate me to improve several things in D62098.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190521/86a6ec75/attachment.html>