Vivien Millet via llvm-dev
2019-Feb-25 16:03 UTC
[llvm-dev] [IR][AsmPrinter][MCJIT]: ensure every x64 "CALL" to Jit function uses relative address
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/20190225/3daa7a5d/attachment.html>
Vivien Millet via llvm-dev
2020-Feb-29 16:11 UTC
[llvm-dev] [IR][AsmPrinter][MCJIT]: ensure every x64 "CALL" to Jit function uses relative address
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>
Lang Hames via llvm-dev
2020-Mar-04 21:45 UTC
[llvm-dev] [IR][AsmPrinter][MCJIT]: ensure every x64 "CALL" to Jit function uses relative address
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>