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

            Bug ID: 30844
           Summary: ld riscv: --emit-relocs does not retain the original
                    relocation type
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: i at maskray dot me
  Target Milestone: ---

From
https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation#ld---emit-relocs
(with updated instructions)

For GNU ld's AArch64/PPC64/x86-64 ports, the --emit-relocs code retains the
original relocation type even if a linker optimization is applied. This is
partly to communicate more information to the analysis tool and partly because
the transformation may not be described with any existing relocation type.

However, the RISC-V port changes the relocation type, including relocation
types for relaxable instructions (e.g. R_RISCV_CALL_PLT), and markers
(R_RISCV_ALIGN and R_RISCV_RELAX). I believe this was not a deliberate decision
as there is no --emit-relocs test at all in ld/testsuite/ld-riscv-elf/. So far,
the unintentional change seems fine but certain relaxations (such as TLSDESC)
may not have relocation types associated with the relaxed instructions.

cat > aarch64.s <<'eof'
.global _start; _start:
  adrp    x1, :got:x
  ldr     x1, [x1, #:got_lo12:x]
.data; .globl x; .hidden x; x: .word 0
eof
cat > ppc64.s <<'eof'
.globl _start; _start:
  addis 3, 2, .Lhidden@toc@ha
  ld    3, .Lhidden@toc@l(3)
  lwa   3, 0(3)
.data; .globl hidden; .hidden hidden; hidden: .long 0
.section .toc,"aw",@progbits
.Lhidden: .tc hidden[TC], hidden
eof
cat > x86-64.s <<'eof'
.globl _start; _start:
  movq foo@gotpcrel(%rip), %rax
foo: nop
eof

aarch64-linux-gnu-gcc -fuse-ld=lld -B/tmp/Rel/bin -nostdlib aarch64.s
-Wl,--emit-relocs -o aarch64 && aarch64-linux-gnu-objdump -dr aarch64 | sed -E
'/^\s*$/d'
powerpc64le-linux-gnu-gcc -nostdlib ppc64.s -Wl,--emit-relocs -o ppc64 &&
powerpc64le-linux-gnu-objdump -dr ppc64 | sed -E '/^\s*$/d'
gcc -nostdlib x86-64.s -Wl,--emit-relocs -o x86-64 && objdump -dr x86-64 | sed
-E '/^\s*$/d'

cat > riscv64.s <<'eof'
.global _start; _start:
  call f
  call f
  .balign 8
f: ret
eof

riscv64-linux-gnu-gcc -nostdlib riscv64.s -Wl,--emit-relocs -o riscv64 &&
riscv64-linux-gnu-objdump -dr riscv64 | sed -E '/^\s*$/d'

Output (removed blank lines for compacter output):
```
aarch64:     file format elf64-littleaarch64
Disassembly of section .text:
00000000000102f8 <_start>:
   102f8:       d503201f        nop
                        102f8: R_AARCH64_ADR_GOT_PAGE   x
   102fc:       10100661        adr     x1, 303c8 <x>
                        102fc: R_AARCH64_LD64_GOT_LO12_NC       x
ppc64:     file format elf64-powerpcle
Disassembly of section .text:
0000000000000240 <_start>:
 240:   00 00 00 60     nop
                        240: R_PPC64_TOC16_HA   hidden
 244:   00 81 62 38     addi    r3,r2,-32512
                        244: R_PPC64_TOC16_LO   hidden
 248:   02 00 63 e8     lwa     r3,0(r3)
x86-64:     file format elf64-x86-64
Disassembly of section .text:
00000000000012dd <_start>:
    12dd:       48 8d 05 00 00 00 00    lea    0x0(%rip),%rax        # 12e4
<foo>
                        12e0: R_X86_64_REX_GOTPCRELX    foo-0x4
00000000000012e4 <foo>:
    12e4:       90                      nop
riscv64:     file format elf64-littleriscv
Disassembly of section .text:
00000000000002a0 <_start>:
 2a0:   008000ef                jal     2a8 <f>
                        2a0: R_RISCV_JAL        f
 2a4:   004000ef                jal     2a8 <f>
                        2a4: R_RISCV_NONE       *ABS*+0x4
                        2a4: R_RISCV_JAL        f
00000000000002a8 <f>:
 2a8:   8082                    ret
                        2a8: R_RISCV_NONE       *ABS*+0x4
                        2a8: R_RISCV_NONE       *ABS*+0x6
```

I have a section "ld --emit-relocs" with very brief information on my website
for a while. Recently https://reviews.llvm.org/D159082 motivated me to
elaborate and bring this up:)

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

Reply via email to