[llvm-dev] [IR][AsmPrinter][MCJIT]: ensure every x64 "CALL" to Jit function uses relative address

[Lang Hames via llvm-dev]

Hi Vivien,

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.

Kind Regards,
Lang.

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.
>>
>> Cheers.
>>
>> Tim.
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190220/70a6dc6e/attachment.html>