[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

16

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

1

# is more common for RISC-V tests.

4

-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

89

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

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

1

#

8

Add { to be clear it is paired with }

[jrtc27]

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

89

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

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

65

MC and LLD support should be separate commits

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

6

Just use .?

[leonardchan]

Split the patches in two: D143226 has the llvm parts

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

89

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 %t2
+// RUN: llvm-objdump -s --section=.data %t2 | 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

 # HEX-NEXT: 03000000 00000000 04000000
 .data
 .p2align 3
 .quad target+3
 .long target+4
 
 # PC-NOT:      .plt:
 # PLT:         .plt:
+
+.word target@plt - .
+# RELOC:      0xC R_RISCV_PLT32 target 0x0

llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def

 ELF_RELOC(R_RISCV_RELAX,             51)
 ELF_RELOC(R_RISCV_SUB6,              52)
 ELF_RELOC(R_RISCV_SET6,              53)
 ELF_RELOC(R_RISCV_SET8,              54)
 ELF_RELOC(R_RISCV_SET16,             55)
 ELF_RELOC(R_RISCV_SET32,             56)
 ELF_RELOC(R_RISCV_32_PCREL,          57)
 ELF_RELOC(R_RISCV_IRELATIVE,         58)
+ELF_RELOC(R_RISCV_PLT32,             59)

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

 //===-- RISCVELFObjectWriter.cpp - RISCV ELF Writer -----------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "MCTargetDesc/RISCVFixupKinds.h"
 #include "MCTargetDesc/RISCVMCExpr.h"
 #include "MCTargetDesc/RISCVMCTargetDesc.h"
 #include "llvm/MC/MCContext.h"
 #include "llvm/MC/MCELFObjectWriter.h"
 #include "llvm/MC/MCFixup.h"
 #include "llvm/MC/MCObjectWriter.h"
+#include "llvm/MC/MCValue.h"
 #include "llvm/Support/ErrorHandling.h"
 
 using namespace llvm;
 
 namespace {
 class RISCVELFObjectWriter : public MCELFObjectTargetWriter {
 public:
   RISCVELFObjectWriter(uint8_t OSABI, bool Is64Bit);
if (Kind >= FirstLiteralRelocationKind)
     return Kind - FirstLiteralRelocationKind;
   if (IsPCRel) {
     switch (Kind) {
     default:
       Ctx.reportError(Fixup.getLoc(), "Unsupported relocation type");
       return ELF::R_RISCV_NONE;
     case FK_Data_4:
     case FK_PCRel_4:
-      return ELF::R_RISCV_32_PCREL;
+      return Target.getAccessVariant() == MCSymbolRefExpr::VK_PLT
+                 ? ELF::R_RISCV_PLT32
+                 : ELF::R_RISCV_32_PCREL;
     case RISCV::fixup_riscv_pcrel_hi20:
       return ELF::R_RISCV_PCREL_HI20;
     case RISCV::fixup_riscv_pcrel_lo12_i:
       return ELF::R_RISCV_PCREL_LO12_I;
     case RISCV::fixup_riscv_pcrel_lo12_s:
       return ELF::R_RISCV_PCREL_LO12_S;
     case RISCV::fixup_riscv_got_hi20:
       return ELF::R_RISCV_GOT_HI20;

llvm/lib/Target/RISCV/RISCVTargetObjectFile.cpp

 #include "llvm/MC/MCSectionELF.h"
 
 using namespace llvm;
 
 void RISCVELFTargetObjectFile::Initialize(MCContext &Ctx,
                                           const TargetMachine &TM) {
   TargetLoweringObjectFileELF::Initialize(Ctx, TM);
 
+  PLTRelativeVariantKind = MCSymbolRefExpr::VK_PLT;
+
   SmallDataSection = getContext().getELFSection(
       ".sdata", ELF::SHT_PROGBITS, ELF::SHF_WRITE | ELF::SHF_ALLOC);
   SmallBSSSection = getContext().getELFSection(".sbss", ELF::SHT_NOBITS,
                                                ELF::SHF_WRITE | ELF::SHF_ALLOC);
 }
 
 // A address must be loaded from a small section if its size is less than the
 // small section size threshold. Data in this section could be addressed by

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

+// RUN: llvm-mc -triple=riscv64 -filetype=obj %s -o - | \
+// RUN:   llvm-readobj -r - | FileCheck %s
+
+  .section .data
+this:
+  .word extern_func@PLT - this + 4
+
+// CHECK:      Section ({{.*}}) .rela.data
+// CHECK-NEXT:   0x0 R_RISCV_PLT32 extern_func 0x4
+// CHECK-NEXT: }