<div dir="ltr">Hi Vivien,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Kind Regards,</div><div>Lang.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 9, 2019 at 12:05 PM Vivien Millet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Sorry I meant 0xE8, 0xFF was in my head because of disassembling and seeing it in use, my bad.<br>Ok I didn't thought about PIC, 

that's a good idea !  ... I forgot it existed at the wrong moment I guess ... <br>How can I modify the GOT then ? <br>Is there an api somewhere in the execution engine / MCJIT ? <br>Or is it somewhere else ?<br>Or I need to accept the idea of hacking stuff inside the LLVM code myself ?<br><br><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 9 févr. 2019 à 20:38, Tim Northover <<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Sat, 9 Feb 2019 at 17:38, Vivien Millet via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Is it possible to tell LLVM somewhere that we prefer the asm printer to use x64 relative CALL  (0xFF) instead of absolute one?<br>
<br>
0xff is always absolute, isn't it? And for JITs the relative variants<br>
are problematic because you normally can't guarantee your mmapped<br>
region will be within  2GB of of what it's calling, so the offset may<br>
be too big.<br>
<br>
> The goal is to be able to move the entire JIT program memory somewhere else and still be able to run the program.<br>
<br>
It sounds like you need to configure the ExecutionEngine to use PIC<br>
mode with setRelocationModel. With that, LLVM do some GOT magic to get<br>
the right address to jump to and then use an absolute jump to that<br>
register. You still have to arrange for the GOT to contain the right<br>
value (looks like it's the address of the function relative to the<br>
start of the GOT at first glance), but that's more tractable than<br>
monkey-patching all the callsites.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>