[PATCH] D97899: [RuntimeDyld] Support more relocations

[Rafael Auler via Phabricator via llvm-commits]

rafauler added a comment.

I took a look at JITLink, including the design document, and it doesn't look like it will need to support 8B and 16B relocs. It looks like it was developed to support code generated by LLVM and LLVM will never emit those. According to the x86-64-psABI document:

  A program or object file using R_X86_64_8, R_X86_64_16, R_X86_64_PC16 or R_X86_64_PC8 relocations is not conformant to this ABI, these relocations are only added for documentation purposes. The R_X86_64_16, and R_X86_64_8 relocations truncate the computed value to 16-bits resp. 8-bits.

The challenge with a tool like BOLT that consumes arbitrary executables in its input is that it needs to support code from multiple compilers/people and assembly-language programmers can get pretty creative, violating the ABI without realizing they are doing so.

BOLT works by using LLVM's tablegen'd disassembler to read a final binary (already linked), building an IR on top of MCInsts, running transformation passes on it and then using MCStreamer to generate an object file that represents the rearranged binary. At this step, it needs RuntimeDyld to resolve relocations emitted by MCStreamer. That's why we end up using a wider range of relocation types.

If you still think it is valuable, I'll definitely go ahead and add those. If the plan is to deprecate RuntimeDyld for good, let me know too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97899