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

[Lang Hames via Phabricator via llvm-commits]

lhames added a comment.

In D147544#4247007 <https://reviews.llvm.org/D147544#4247007>, @rafauler wrote:

>> 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.

Is this operating per-function and patching the relocated code for that function back into the original binary then? I had assumed that you were creating a whole new ELF container.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147544