[lld][RISCV] Introduce handling for R_RISCV_PLT32 relocation

[leonardchan]

Summary

This introduces R_RISCV_PLT32, a PC-relative data relocation that takes the 32-bit relative offset to a function or its PLT entry.

This is needed to support relative vtables on RISCV.

Github PR: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/363

D143226 has the llvm parts.

[craig.topper]

I think you meant [lld] in the title?

[leonardchan]

In D143115#4097967, @craig.topper wrote:

I think you meant [lld] in the title?

Yeah this has both llvm and lld changes so I just happen to pick [llvm'. In hindsight this should probably be two separate llvm and lld patches, but I'll leave that up for reviewers to decide if it's necessary.

[mcgrathr]

lgtm but we should probably wait for Fangrui's review too.

lld/test/ELF/riscv-reloc-plt32.s

17

Indentation here is a bit funny.

[MaskRay]

Generally looks good, pending approval of the psABI proposal and test cleanup.

This introduces R_RISCV_PLT32, a pc-relative relocation that takes the offset to a function (or its plt entry) from the reloc's location.

"PC-relative data relocation".

"32-bit relative offset to a function or its PLT entry".

lld/test/ELF/riscv-reloc-plt32.s

2

# is more common for RISC-V tests.

5

-o %t

In new tests, make the output name match the primary relocatable object file. If we ever need %t2.o, we can name its output file %t2.

lld/test/ELF/riscv-undefined-weak.s

103

Place the CHECK line above the instruction (the style used in this test file).

llvm/test/MC/RISCV/elf-reloc-plt32.s

1 ↗

(On Diff #494088)

#

8 ↗

(On Diff #494088)

Add { to be clear it is paired with }

[jrtc27]

lld/test/ELF/riscv-undefined-weak.s

103

This also needs a HEX, otherwise you're not testing the linker at all here.

llvm/lib/Target/RISCV/MCTargetDesc/RISCVELFObjectWriter.cpp

65 ↗

(On Diff #494088)

MC and LLD support should be separate commits

llvm/test/MC/RISCV/elf-reloc-plt32.s

6 ↗

(On Diff #494088)

Just use .?

[leonardchan]

Split the patches in two: D143226 has the llvm parts

lld/test/ELF/riscv-undefined-weak.s

103

Uhh. Added one, but checking the actual hex dynamically is a bit difficult in lit. I can get individual addresses from objdump then do arithmetic in lit, but don't know a way to flip the result to match the endianness of objdump's output, so I hope the comments in the updated patch explain well enough.

[asb]

@kito-cheng @jrtc27: Can I just confirm the ABI development process? We obviously went through a whole ratification exercise before, but how does it now work for these kind of additions? I'm mainly concerned about merging support for something that's added to the psABI doc, but then having to change it later if it's viewed as not "final". I guess this shouldn't happen, as a consequence of the PR merging policy but it's still a bit unclear how it intersects with any future ratification process that might be requested by RISC-V International.

Though FWIW, I think the path of getting broad consensus on the proposal and then considering it 'done' is just fine - I'm not sure extra layers of sign-off would be helpful for incremental improvements like this. And in case I missed a hidden layer of bureaucracy, I _think_ the x86_64 psABI is evolved in a similar way.

[jrtc27]

In D143115#4149693, @asb wrote:

@kito-cheng @jrtc27: Can I just confirm the ABI development process? We obviously went through a whole ratification exercise before, but how does it now work for these kind of additions? I'm mainly concerned about merging support for something that's added to the psABI doc, but then having to change it later if it's viewed as not "final". I guess this shouldn't happen, as a consequence of the PR merging policy but it's still a bit unclear how it intersects with any future ratification process that might be requested by RISC-V International.

Though FWIW, I think the path of getting broad consensus on the proposal and then considering it 'done' is just fine - I'm not sure extra layers of sign-off would be helpful for incremental improvements like this. And in case I missed a hidden layer of bureaucracy, I _think_ the x86_64 psABI is evolved in a similar way.

My view is the ratification lifecycle is incompatible with toolchain software development, especially ABIs. We’ve mostly been ignoring it other than to get the spec approved, but a system where the ABI says one thing in one draft and something incompatible in a later draft renders the document useless for most of the year. I guess the exception would be an ABI that specifically refers to a draft extension and thus of course will evolve with the extension.

lld/ELF/Arch/RISCV.cpp

RelExpr RISCV::getRelExpr(const RelType type, const Symbol &s,
   case R_RISCV_BRANCH:
   case R_RISCV_PCREL_HI20:
   case R_RISCV_RVC_BRANCH:
   case R_RISCV_RVC_JUMP:
   case R_RISCV_32_PCREL:
     return R_PC;
   case R_RISCV_CALL:
   case R_RISCV_CALL_PLT:
+  case R_RISCV_PLT32:
     return R_PLT_PC;
   case R_RISCV_GOT_HI20:
     return R_GOT_PC;
   case R_RISCV_PCREL_LO12_I:
   case R_RISCV_PCREL_LO12_S:
     return R_RISCV_PC_INDIRECT;
   case R_RISCV_TLS_GD_HI20:
     return R_TLSGD_PC;
void RISCV::relocate(uint8_t *loc, const Relocation &rel, uint64_t val) const {
   case R_RISCV_SET8:
     *loc = val;
     return;
   case R_RISCV_SET16:
     write16le(loc, val);
     return;
   case R_RISCV_SET32:
   case R_RISCV_32_PCREL:
+  case R_RISCV_PLT32:
     write32le(loc, val);
     return;
 
   case R_RISCV_TLS_DTPREL32:
     write32le(loc, val - dtpOffset);
     break;
   case R_RISCV_TLS_DTPREL64:
     write64le(loc, val - dtpOffset);

lld/ELF/InputSection.cpp

 static uint64_t getRISCVUndefinedRelativeWeakVA(uint64_t type, uint64_t p) {
   switch (type) {
   case R_RISCV_BRANCH:
   case R_RISCV_JAL:
   case R_RISCV_CALL:
   case R_RISCV_CALL_PLT:
   case R_RISCV_RVC_BRANCH:
   case R_RISCV_RVC_JUMP:
+  case R_RISCV_PLT32:
     return p;
   default:
     return 0;
   }
 }
 
 // ARM SBREL relocations are of the form S + A - B where B is the static base
 // The ARM ABI defines base to be "addressing origin of the output segment

lld/test/ELF/riscv-reloc-plt32.s

+# RUN: llvm-mc -filetype=obj -triple=riscv64 %s -o %t.o
+# RUN: llvm-mc -filetype=obj -triple=riscv64 %S/Inputs/abs256.s -o %t256.o
+#
+# RUN: ld.lld -z max-page-size=4096 %t.o %t256.o -o %t
+# RUN: llvm-objdump -s --section=.data %t | FileCheck %s
+#
+# CHECK: Contents of section .data:
+## 12158: S = 0x100, A = 0, P = 0x12158
+##        S + A - P = 0xfffedfa8
+## 1215c: S = 0x100, A = 1, P = 0x1215c
+##        S + A - P = 0xfffedfa5
+## 12160: S = 0x100, A = -1, P = 0x12160
+##        S + A - P = 0xfffedf9f
+# CHECK-NEXT: 12158 a8dffeff a5dffeff 9fdffeff
+
+.globl _start
+_start:
+.data
+  .word foo@PLT - .
+  .word foo@PLT - . + 1
+  .word foo@PLT - . - 1

lld/test/ELF/riscv-undefined-weak.s

 # REQUIRES: riscv
 # RUN: llvm-mc -filetype=obj -triple=riscv64 %s -o %t.o
 # RUN: llvm-readobj -r %t.o | FileCheck --check-prefix=RELOC %s
 
 # RUN: ld.lld -e absolute %t.o -o %t
 # RUN: llvm-objdump -d --no-show-raw-insn %t | FileCheck --check-prefixes=CHECK,PC %s
-# RUN: llvm-readelf -x .data %t | FileCheck --check-prefixes=HEX %s
+# RUN: llvm-readelf -x .data %t | FileCheck --check-prefixes=HEX,HEX-WITHOUT-PLT %s
 
 # RUN: ld.lld -e absolute %t.o -o %t --export-dynamic
 # RUN: llvm-objdump -d --no-show-raw-insn %t | FileCheck --check-prefixes=CHECK,PLT %s
-# RUN: llvm-readelf -x .data %t | FileCheck --check-prefixes=HEX %s
+# RUN: llvm-readelf -x .data %t | FileCheck --check-prefixes=HEX,HEX-WITH-PLT %s
 
 .weak target
 .global absolute, relative, branch
 
 ## Absolute relocations are resolved to 0.
 # RELOC:      0x0 R_RISCV_HI20 target 0x1
 # RELOC-NEXT: 0x4 R_RISCV_LO12_I target 0x1
 

 branch:
   call target
   jal x0, target
   beq x0, x0, target
 
 ## Absolute relocations are resolved to 0.
 # RELOC:      0x0 R_RISCV_64 target 0x3
 # RELOC-NEXT: 0x8 R_RISCV_32 target 0x4
+# RELOC-NEXT: 0xC R_RISCV_PLT32 target 0x0
+
 # HEX:      section '.data':
 # HEX-NEXT: 03000000 00000000 04000000
+# HEX-WITHOUT-PLT-SAME: 00000000
+
+## A plt entry is created for target, so this is the offset between the
+## plt entry and this address.
+##
+##   S = 0x11360 (the address of the plt entry for target)
+##   A = 0
+##   P = 0x1343c (the address of `.`)
+##
+##   S - A + P = -0x0x20dc = 0xffffdf24
+# HEX-WITH-PLT-SAME: 24dfffff
+
 .data
 .p2align 3
 .quad target+3
 .long target+4
 
 # PC-NOT:      .plt:
 # PLT:         .plt:
+
+.word target@plt - .