[PATCH] D147544: [BOLT] Move from RuntimeDyld to JITLink

Rafael Auler via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 5 14:10:22 PDT 2023


rafauler added a comment.

> Is BOLT taking a relocatable file as input, or an executable / dylib?

BOLT's input is a final executable / .so file.

Here's how BOLT operates at a high level.

1. Run a disassembler to create MCInst objects for each instruction in a function it wants to patch.  (it does more than that, such as creating cfgs, but I'll skip for the purposes of this discussion)
2. After MCInsts get shuffled around to take advantage of a better code layout, we wend it to the assembler (via the MCStreamer interface).
3. Assembler resolves internal fixups, generates regular ELF relocations for symbols that are not local (for example, references to other functions or global data in that binary).
4. We feed that to RuntimeDyld to patch these relocations for us. RuntimeDyld actually has no idea where are these global symbols, so it asks us "where is foobar", we know where it is because we read the full symbol table of that binary (and using other techniques as well), so we answer RuntimeDyld back with all of the addresses it needs to resolve.
5. Relocations are processed and the code is available in a blob of memory.
6. We copy that blob of memory back to the final binary, at the location we want to patch.

BOLT has different modes of operation too, but at a high level, from a linker perspective, that's what it is doing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147544



More information about the llvm-commits mailing list