[Lldb-commits] [PATCH] D90769: [lldb][ObjectFile] Relocate sections for in-memory objects (e.g. received via JITLoaderGDB)

Fri Nov 6 00:03:00 PST 2020

labath added a comment.

In D90769#2376557 <https://reviews.llvm.org/D90769#2376557>, @sgraenitz wrote:

> Thanks for having a look!
>
> The JIT implementations in LLVM operate on relocatable object files, so someone needs to resolve them. MCJIT has a flag `ProcessAllSections` to control which sections will be loaded and relocated. As it is off by default, it will usually ignore sections that it doesn't need for execution. LLDB does it the other way around in ObjectFileELF::RelocateSection(), it only processes sections with the ".debug" prefix. This seems to be a reasonable distribution of tasks. In general, relocations are resolved in place, so it doesn't rise memory consumption.

But you still have to allocate memory to store the relocations. And that memory is not freed after the relocations are resolved, right?

>> I do wonder though if the jit could be changed to avoid relocation.
>
> Well, I don't think we are anywhere close to optimizations like this, but it would be nice indeed. If we compile from bitcode on the JIT side, we could lookup external symbols at compile-time and don't produce relocations for them in the first place. I guess it would heavily reduce the number of relocations and potentially save time. On the other hand, thinking about concurrent compile jobs and cross-dependencies.. I can imagine it gets hairy quickly. Plus: the way it is now, we can cache the object files and reuse them thanks to position-independent code.

In a "normal" compilation, there are two kinds of relocations. The ones that are resolved by the normal (static) linker, and the ones that are resolved by the dynamic linker (loader). to make a module relocatable and have it interface with external code, you only need the second kind. The debug info relocations are all of the first kind, so they could be resolved (or, not emitted in the first place -- like what happens with MachO object files) without impacting this ability.

But that's for another discussion...

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90769