[PATCH] D143673: [lld][RISCV] Implement GP relaxation for R_RISCV_HI20/R_RISCV_LO12_I/R_RISCV_LO12_S.

Wed Feb 22 16:40:42 PST 2023

craig.topper added a comment.

Given that GP is already reserved at least for linux can this patch move forward?

================
Comment at: llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def:49
 ELF_RELOC(R_RISCV_RVC_LUI,           46)
+ELF_RELOC(R_RISCV_GPREL_I,           47)
+ELF_RELOC(R_RISCV_GPREL_S,           48)
----------------
craig.topper wrote:
> craig.topper wrote:
> > jrtc27 wrote:
> > > craig.topper wrote:
> > > > jrtc27 wrote:
> > > > > These don't exist, they were removed as they were solely internal to binutils, and their encodings are reserved for future standard use
> > > > Is binutils only going to be updated to use different values when a new standard use is introduced?
> > > > 
> > > > Is there a safe number to use for LLD insternal use?
> > > So long they're not permitted in inputs it's "fine" as it won't misinterpret future files, but using ELF_RELOC here means all the other tools will think this is a real relocation (e.g. llvm-readelf will decode it). Can you not just use R_RISCV_RELAX like for TLS, though? It seems you're doing the exact same thing.
> > In order to support .sbss, I believe I need to create a relocation to communicate from the instruction relaxation phase to the `relax` function which runs later. When I tried to rewrite .sbss globals in `relaxHi20Lo12` I got the wrong addresses. My thinking was that I needed the .text section to shrink and the layout of later sections to adjust before I could do the instruction rewriting.
> Since R_RISCV_GPREL_I/R_RISCV_GPREL_S are in the normal relocation list in binutils, doesn't that mean binutils readelf will also think they are real relocations?
@jrtc27 what should I do here? As I said, I think GNU readelf also thinks they are real relocations.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143673/new/

https://reviews.llvm.org/D143673