<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 INVALID - lld produces an empty relocation if it did target a discarded section"
href="https://bugs.llvm.org/show_bug.cgi?id=51047">bug 51047</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;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>INVALID
</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 INVALID - lld produces an empty relocation if it did target a discarded section"
href="https://bugs.llvm.org/show_bug.cgi?id=51047#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - lld produces an empty relocation if it did target a discarded section"
href="https://bugs.llvm.org/show_bug.cgi?id=51047">bug 51047</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>tl;dr I think the correct behavior is unclear and GNU ld is not necessarily
correct.
I'll note first that Clang 13.0 will have a behavior change
(<a href="https://reviews.llvm.org/D100944">https://reviews.llvm.org/D100944</a>) for
__attribute__((__section__(".debug_info"))) char *xp = &x;
The code previously caused a non-SHF_ALLOC .debug_info section.
It causes a SHF_ALLOC|SHF_WRITE .debug_info section now.
---
Whether or not the .debug_info has the SHF_ALLOC flag, objcopy/llvm-objcopy
will report an error.
% objcopy -R discardme discard.o /dev/null
objcopy: /dev/null: symbol `x' required but not present
objcopy: /dev/null: no symbols
% llvm-objcopy -R discardme discard.o /dev/null
llvm-objcopy: error: 'discard.o': section 'discardme' cannot be removed:
(.debug_info+0x0) has relocation against symbol 'x'
ld.bfd's behavior is dependent on whether the SHF_ALLOC flag is present.
For SHF_ALLOC,
% ld.bfd -r -m elf_x86_64 -T discard.lds -o discard2.o discard.o
`x' referenced in section `.debug_info' of discard.o: defined in discarded
section `discardme' of discard.o
For non-SHF_ALLOC, it allows the link and converts R_X86_64_64 to
R_X86_64_NONE.
But I am not sure R_X86_64_NONE is better than removing the symbol part from
the relocation.
Note that the .debug_* case comes from a very early design decision/compromise:
fragmented text sections with monolithic debug sections.
The expectation is that the linker doesn't error for relocations referencing
symbols defined relative to discarded sections.
ld.lld just treats SHF_ALLOC similar to non-SHF_ALLOC.
gold's behavior isn't bad, either.
x is kept as an undefined symbol. This is similar to a non-prevailing member in
a GRP_COMDAT section group.
The code should be fixed to remove reliance on the particular behavior.</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>