This is an archive of the discontinued LLVM Phabricator instance.

[RuntimeDyld] Support more relocations
ClosedPublic

Authored by rafauler on Mar 3 2021, 5:50 PM.

Details

Summary

This patch introduces functionality used by BOLT when
re-linking the final binary. It adds new relocation types that
are currently unsupported by RuntimeDyldELF.

Diff Detail

Event Timeline

rafauler created this revision.Mar 3 2021, 5:50 PM
rafauler requested review of this revision.Mar 3 2021, 5:50 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2021, 5:50 PM
lhames accepted this revision.Mar 10 2021, 7:59 AM

LGTM.

Any interest in adding those relocation types to JITLink's ELF/x86-64 backend (llvm/lib/ExecutionEngine/JITLink/ELF_x86_64.cpp)? I'm planning to have LLJIT use JITLink by default for ELF/x86-64 in LLVM 13.

This revision is now accepted and ready to land.Mar 10 2021, 7:59 AM

Sure, let me take a look at that.

This revision was landed with ongoing or failed builds.Mar 10 2021, 11:20 AM
This revision was automatically updated to reflect the committed changes.

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.

The R_X86_64_8 range checking is wrong. See D63690.
It also feels wrong to use assert because the relocation overflow can happen and ExecutionEngine should not crash in that case.

LLVM only emits R_X86_64_8 for !absolute_symbol. I think R_X86_64_16 is not used.

Thanks, MaskRay, I'll fix this