This is an archive of the discontinued LLVM Phabricator instance.

[JITLink][RISCV] Handle R_RISCV_CALL_PLT fixups
ClosedPublic

Authored by jobnoorman on Apr 13 2023, 8:20 AM.

Details

Summary

In the default link configuration, PLT stubs are created automatically
for R_RISCV_CALL_PLT relocations and the relocation itself is
transformed to R_RISCV_CALL (PerGraphGOTAndPLTStubsBuilder_ELF_riscv).
Only the latter is later handled when applying fixups and the former is
simply ignored.

This patch proposes to handle R_RISCV_CALL_PLT anyway when applying
fixups to support custom configurations that do not need automatic PLT
creation. An example of this is BOLT where PLT entries from the input
binary are reused (D147544).

As a side note, I would like to point out that R_RISCV_CALL has been
deprecated. [1] Both GCC and LLVM seem to not generate it anymore and
always use R_RISCV_CALL_PLT (even for calls that do not need a PLT
entry). So I'm not sure if the current strategy of generating PLT
entries based on relocation type is correct. This [2] suggests basing
this on whether the target symbol is preemptable.

[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/340
[2] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/98

Diff Detail

Event Timeline

jobnoorman created this revision.Apr 13 2023, 8:20 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 13 2023, 8:20 AM
Herald added subscribers: asb, luke, pmatos and 29 others. · View Herald Transcript
jobnoorman requested review of this revision.Apr 13 2023, 8:20 AM

So I'm not sure if the current strategy of generating PLT entries based on relocation type is correct.

It is not and never has been (think linking -fPIC code into an executable that calls a defined symbol).

This [2] suggests basing this on whether the target symbol is preemptable.

Yes.

This revision is now accepted and ready to land.Apr 13 2023, 9:17 PM
This revision was automatically updated to reflect the committed changes.