This is an archive of the discontinued LLVM Phabricator instance.

[lld][RISCV] Introduce handling for R_RISCV_PLT32 relocation
ClosedPublic

Authored by leonardchan on Feb 1 2023, 3:32 PM.

Details

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.

Diff Detail

Event Timeline

leonardchan created this revision.Feb 1 2023, 3:32 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 1 2023, 3:32 PM
leonardchan requested review of this revision.Feb 1 2023, 3:32 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 1 2023, 3:32 PM

I think you meant [lld] in the title?

leonardchan retitled this revision from [llvm][RISCV] Introduce handling for R_RISCV_PLT32 relocation to [lld][RISCV] Introduce handling for R_RISCV_PLT32 relocation.Feb 1 2023, 3:38 PM

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 accepted this revision.Feb 2 2023, 9:31 AM

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.

This revision is now accepted and ready to land.Feb 2 2023, 9:31 AM
MaskRay accepted this revision.Feb 2 2023, 9:52 AM

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 added inline comments.Feb 2 2023, 1:22 PM
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 .?

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.

leonardchan edited the summary of this revision. (Show Details)Feb 2 2023, 3:53 PM
leonardchan edited the summary of this revision. (Show Details)
This revision was landed with ongoing or failed builds.Feb 23 2023, 2:06 PM
This revision was automatically updated to reflect the committed changes.
asb added a comment.Feb 24 2023, 1:03 AM

@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.

@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.