[Bug ld/28709] [RISC-V] a unused section can't be removed with -gc-sections

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28709

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-12-20

--- Comment #1 from Alan Modra <amodra at gmail dot com> ---
The problem is actually that you have out-of-order relocations in .eh_frame.

Relocation section '.rela.eh_frame' at offset 0x538 contains 8 entries:
    Offset             Info             Type               Symbol's Value 
Symbol's Name + Addend
000000000000001c  0000000800000039 R_RISCV_32_PCREL       0000000000000000 .L0 
+ 0
0000000000000020  0000000c00000023 R_RISCV_ADD32          000000000000003e .L0 
+ 0
0000000000000020  0000000800000027 R_RISCV_SUB32          0000000000000000 .L0 
+ 0
0000000000000040  0000000f00000039 R_RISCV_32_PCREL       0000000000000000 .L0 
+ 0
0000000000000044  0000001100000023 R_RISCV_ADD32          0000000000000002 .L0 
+ 0
0000000000000044  0000000f00000027 R_RISCV_SUB32          0000000000000000 .L0 
+ 0
000000000000002f  0000000b00000035 R_RISCV_SET6           000000000000003a .L0 
+ 0
000000000000002f  0000000a00000034 R_RISCV_SUB6           0000000000000006 .L0 
+ 0

When the linker is marking the FDE for _GLOBAL__sub_I__ZN3Box3getEv it starts
correctly at the r_offset 0x40 reloc marking that and the two r_offset 0x44
relocs.  Those all point at _GLOBAL__sub_I__ZN3Box3getEv. (Watch out for tricky
multiple .L0 symbols, it's easy to get confused over which section they belong
to!  You need to look at the index in r_info.)  Then the two out-of-order
relocs at 0x2f are encountered, and processed as if they are part of the
_GLOBAL__sub_I__ZN3Box3getEv FDE.  Those particular .L0s are defined in
.text.test111111, which is why .text.test111111 is marked as needed.

Disabling .eh_frame marking is *not* the solution.  You should figure out why
the assembler is generating relocs out-of-order and fix that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.