[llvm-dev] [IR][AsmPrinter][MCJIT]: ensure every x64 "CALL" to Jit function uses relative address
Lang Hames via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 20 16:02:01 PST 2019
RuntimeDyld (the JIT-linker currently underlying MCJIT and ORC) requires
large code model, which I believe renders this discussion moot since all
jumps are via registers.
I am working on a replacement linker that will support the small code
model. I hope to have prototypes out for review next week. In the new model
you will be able to register a callback to inspect the linkers data
structures: this could be used to identify the location of each jump stub
and jump-stub pointer.
On Sat, Feb 9, 2019 at 12:05 PM Vivien Millet via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Sorry I meant 0xE8, 0xFF was in my head because of disassembling and
> seeing it in use, my bad.
> Ok I didn't thought about PIC, that's a good idea ! ... I forgot it
> existed at the wrong moment I guess ...
> How can I modify the GOT then ?
> Is there an api somewhere in the execution engine / MCJIT ?
> Or is it somewhere else ?
> Or I need to accept the idea of hacking stuff inside the LLVM code myself ?
> Le sam. 9 févr. 2019 à 20:38, Tim Northover <t.p.northover at gmail.com> a
> écrit :
>> On Sat, 9 Feb 2019 at 17:38, Vivien Millet via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > Is it possible to tell LLVM somewhere that we prefer the asm printer to
>> use x64 relative CALL (0xFF) instead of absolute one?
>> 0xff is always absolute, isn't it? And for JITs the relative variants
>> are problematic because you normally can't guarantee your mmapped
>> region will be within 2GB of of what it's calling, so the offset may
>> be too big.
>> > The goal is to be able to move the entire JIT program memory somewhere
>> else and still be able to run the program.
>> It sounds like you need to configure the ExecutionEngine to use PIC
>> mode with setRelocationModel. With that, LLVM do some GOT magic to get
>> the right address to jump to and then use an absolute jump to that
>> register. You still have to arrange for the GOT to contain the right
>> value (looks like it's the address of the function relative to the
>> start of the GOT at first glance), but that's more tractable than
>> monkey-patching all the callsites.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev