[PATCH] D113038: [ORC] Add a utility for adding missing "self" relocations to a Symbol

Lang Hames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 4 13:18:29 PDT 2021


lhames accepted this revision.
lhames added a comment.
This revision is now accepted and ready to land.

We should fix MC to emit the missing relocations, but we'll have a lot of legacy objects to deal with -- this is a great solution for those.

LGTM.



================
Comment at: llvm/lib/ExecutionEngine/Orc/IndirectionUtils.cpp:447
+    LLVM_DEBUG(dbgs() << "Adding delta32 self-relocation at " << InstrStart);
+    B.addEdge(jitlink::x86_64::Delta32, RelocOffInBlock, Sym, /*Addend=*/-4);
+  }
----------------
benlangmuir wrote:
> I wasn't sure if it was worth zeroing out the existing addend in the instruction stream - it would seem to be "nice" to zero it out to ensure we're depending on the relocation instead of the original addend, but it seems to get overwritten completely when we perform the fixup anyway and the contents of the block need to be copied and made mutable to make any changes.
We've never formalized this as a policy but in practice JITLink relocations always overwrite all operand bits, so it should be safe to leave the existing ones in there. I think leaving the bits as-is is the right trade-off.


================
Comment at: llvm/lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp:412-413
+  Optional<uint64_t>
+  getMemoryOperandRelocationOffset(const MCInst &Inst,
+                                   uint64_t Size) const override;
 };
----------------
My knee-jerk reaction was "what happens if there are multiple memory operands", but we've already got `evaluateMemoryOperandAddress` above so there's some precedent for assuming one memory operand.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113038



More information about the llvm-commits mailing list