<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">t.p.northover@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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>