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.
