[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

Jan Kratochvil <jan.kratochvil at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
             Status|RESOLVED                    |REOPENED

--- Comment #2 from Jan Kratochvil <jan.kratochvil at redhat.com> ---
(In reply to Fangrui Song from comment #1)
> I'll note first that Clang 13.0 will have a behavior change
> (https://reviews.llvm.org/D100944) for

The behavior has not changed, retested with:
LLD 14.0.0 (https://github.com/llvm/llvm-project.git
cf0ddf7ee5522c731b89dc5174b3d370f782119b) = 2021-07-28


> But I am not sure R_X86_64_NONE is better than removing the symbol part from
> the relocation.

https://refspecs.linuxfoundation.org/elf/x86_64-abi-0.95.pdf
Name           Field   Calculation
R_X86_64_NONE  none    none
R_X86_64_64    word64  S+A

R_X86_64_64 requires the S there.
If S is not there it should not be R_X86_64_64.


-------------------------------------------------------------------------------

> The code previously caused a non-SHF_ALLOC .debug_info section.
> It causes a SHF_ALLOC|SHF_WRITE .debug_info section now.

Real world testcase is sure non-SHF_ALLOC - as all normal .debug_* sections.
Here is a non-SHF_ALLOC reproducer:

echo '__attribute__((__section__("discardme"))) char XXX;'|clang -Wall -c -o
discard.o -g -x c -;echo 'SECTIONS { /DISCARD/ : { *(discardme) } }'
>discard.lds;ld.lld -r -m elf_x86_64 -T discard.lds -o discard2.o
discard.o;llvm-readelf -Wr discard2.o

Relocation section '.rela.debug_info' at offset 0xa8 contains 8 entries:
    Offset             Info             Type               Symbol's Value 
Symbol's Name + Addend
000000000000002b  0000000000000001 R_X86_64_64                       0


> objcopy/llvm-objcopy will report an error.

This Bug is not filed against llvm-objcopy.

> ld.bfd's behavior
> For non-SHF_ALLOC, it allows the link and converts R_X86_64_64 to
> R_X86_64_NONE.

Yes. In real world case (Linux kernel compilation) ld.bfd even omits the
relocation completely which is the intended goal. With non-SHF_ALLOC reproducer
above ld.bfd does not produce any relocation (not even R_X86_64_NONE).


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

This does not come from C++ COMDAT. This comes from clang Linux kernel build
with CONFIG_DEBUG_FORCE_WEAK_PER_CPU (or arch defaulting it):
https://github.com/torvalds/linux/blob/06c8839815ac7aa2b44ea3bb3ee1820b08418f55/include/linux/percpu-defs.h#L76

 <1><ab1b>: Abbrev Number: 62 (DW_TAG_variable)
    <ab1c>   DW_AT_name        : (indirect string, offset: 0x9b47):
__pcpu_unique_rcu_torture_count
    <ab20>   DW_AT_type        : <0x51>
    <ab24>   DW_AT_external    : 1
    <ab24>   DW_AT_decl_file   : 1
    <ab25>   DW_AT_decl_line   : 173
    <ab26>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0       
(DW_OP_addr: 0)
    Offset             Info             Type               Symbol's Value 
Symbol's Name + Addend
000000000000ab28  0000000000000001 R_X86_64_64                               0

I do not think one can suppress "-g" for specific symbols in a CU.
.c:2:1: warning: bad option ‘-g0’ to attribute ‘optimize’ [-Wattributes]
.c:3:9: warning: bad option ‘-g0’ to pragma ‘optimize’ [-Wpragmas]
(that is from gcc, clang does not recognize the attribute/pragma)
I am not aware of a DWARF reprocessing tool to drop specific DWARF symbols.


> The code should be fixed to remove reliance on the particular behavior.

Still this Bug is that R_X86_64_64 should not exist with missing symbol S.

-- 
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/20210728/40084b5e/attachment.html>