This is an archive of the discontinued LLVM Phabricator instance.

[ELF][RISCV] Resolve branch relocations referencing undefined weak to current location if not using PLT

Authored by MaskRay on May 23 2021, 8:55 PM.



In a -no-pie link we optimize R_PLT_PC to R_PC. Currently we resolve a branch
relocation to the link-time zero address. However such a choice tends to cause
relocation overflow possibility for RISC architectures.

  • aarch64: GNU ld: rewrite the instruction to a NOP; ld.lld: branch to the next instruction
  • mips: GNU ld: branch to the start of the text segment (?); ld.lld: branch to zero
  • ppc32: GNU ld: rewrite the instruction to a NOP; ld.lld: branch to the current instruction
  • ppc64: GNU ld: rewrite the instruction to a NOP; ld.lld: branch to the current instruction
  • riscv: GNU ld: branch to the absolute zero address (with instruction rewriting)
  • i386/x86_64: GNU ld/ld.lld: branch to the link-time zero address

I think that resolving to the same location is a good choice. The instruction,
if triggered, is clearly an undefined behavior. Resolving to the same location
can cause an infinite loop (making the user aware of the issue) while ensuring
no overflow.

Diff Detail

Event Timeline

MaskRay created this revision.May 23 2021, 8:55 PM
MaskRay requested review of this revision.May 23 2021, 8:55 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 23 2021, 8:55 PM

Looks like GNU as/llvm-mc doesn't use R_RISCV_RVC_JUMP/R_RISCV_RVC_BRANCH for undefined symbols.

MaskRay updated this revision to Diff 347306.May 23 2021, 9:14 PM

improve test

jrtc27 added inline comments.Jun 9 2021, 4:52 PM

Hm, this is a better way of writing it but it's inconsistent with ARM and AArch64.

MaskRay marked an inline comment as done.Jun 9 2021, 5:16 PM
MaskRay added inline comments.

I can change arm/aarch64 to use this style afterward

jrtc27 accepted this revision.Jun 10 2021, 6:09 AM

This isn't specified in the psABI, but I don't think it needs to be (AFAIK Arm's psABI is the only one that does, and it opts for the strange "next instruction" semantics, I guess so you can just skip the NULL check in some cases), it's completely undefined behaviour so should always be in dead code, but not known at compile time so we need to do something.


That's fine with me then

This revision is now accepted and ready to land.Jun 10 2021, 6:09 AM
MaskRay edited the summary of this revision. (Show Details)Jun 10 2021, 1:20 PM