<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:i@maskray.me" title="Fangrui Song <i@maskray.me>"> <span class="fn">Fangrui Song</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - lld ignores addend for weak undefined TLS symbol in static executable"
href="https://bugs.llvm.org/show_bug.cgi?id=40570">bug 40570</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>FIXED
</td>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>i@maskray.me
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - lld ignores addend for weak undefined TLS symbol in static executable"
href="https://bugs.llvm.org/show_bug.cgi?id=40570#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - lld ignores addend for weak undefined TLS symbol in static executable"
href="https://bugs.llvm.org/show_bug.cgi?id=40570">bug 40570</a>
from <span class="vcard"><a class="email" href="mailto:i@maskray.me" title="Fangrui Song <i@maskray.me>"> <span class="fn">Fangrui Song</span></a>
</span></b>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>