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

[Lang Hames via llvm-dev]

Hi Vivien,

Do you have news about your changes planned for the linker ? :)


I do: The new JIT linker is called JITLink and has implementations
available for MachO/x86-64 and MachO/arm64, with an ELF/x86-64
implementation on the way. It supports small code model and linker plugins.
You can find an example of how to write and use linker plugins in
llvm/examples/LLJITExamples/LLJITWithObjectLinkingLayerPlugin.

You mentioned that you want to be able to move code in memory: Can you talk
about the use-case in more detail? JITLink will happily re-link cached
objects, but if you just want to memcpy a buffer containing linked memory
you have to be very careful: Any non-relative references may be broken.
E.g. any GOT or CFI entries for globals defined in the linkage unit whose
buffer you are moving.

-- Lang.


On Sat, Feb 29, 2020 at 8:11 AM Vivien Millet <vivien.millet at gmail.com>
wrote:

> 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/20200304/64fb3a35/attachment.html>