[llvm-bugs] [Bug 51047] lld produces an empty relocation if it did target a discarded section

[via llvm-bugs]

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

Fangrui Song <i at maskray.me> changed:

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

--- Comment #1 from Fangrui Song <i at maskray.me> ---
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
(https://reviews.llvm.org/D100944) 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.

-- 
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/20210722/986618ae/attachment.html>