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

[Vivien Millet via llvm-dev]

Hi Lang,
Do you have news about your changes planned for the linker ? :)
Thanks,
Vivien

Le lun. 25 févr. 2019 à 17:03, Vivien Millet <vivien.millet at gmail.com> a
écrit :

> Hi Lang,
> That would be great ! :)
> For now I found a hack which consist of loading a "full of NOP" DLL, use
> my own DllMemMgr which allocates JIT sections inside the DLL virtual space,
> backup the memory inside some buffers, unload the DLL, copy the buffer
> inside the DLL file, create the PDB, reload the DLL file which hopefully in
> 99% is reloaded at the same virtual address (this allow me to debug with
> PDB after reload). If not reloaded at same address I restart the process
> from the beginning until it does (quite dirty but it really does the job
> until I have a better option).
>
> Keep me in touch with the progress of your work !
> Thanks !
>
> Vivien
>
> Le jeu. 21 févr. 2019 à 01:02, Lang Hames <lhames at gmail.com> a écrit :
>
>> 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/20200229/3eef1752/attachment-0001.html>