<div dir="ltr">Hi Rafael,<div><br></div><div>The callback code is some of the nastiest stuff in the current prototype. I'd love to see it cleaned up.</div><div><br></div><div>I think there may be scope to re-use the GOT/PLT for jumping back in to the JIT, but we'll need some new RuntimeDyld API first: The JIT would need to be able to find and modify GOT entries.</div><div><br></div><div>Cheers,</div><div>Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 22, 2015 at 8:51 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Questions and comments welcome.<br>
<br>
The way lazy compilation is implemented looks odd. My understanding is<br>
that the IR is patched to turn "call @foo" into a load + call into the<br>
JIT.<br>
<br>
Why no just make @foo a declaration and compile with -fPIC? That will<br>
produce a 'call foo@plt' in the produced .o file. With that, our<br>
"dynamic linker" can create a got and a plt. The plt loads the got and<br>
jumps to it. The initial value in the GOT can be to just jump to<br>
MCJIT. Following calls will be direct.<br>
<br>
So the PLT the our dynamic linker creates could look like<br>
<br>
jmpq *got_entry<br>
movq some_jit_created_id_of_the_function $RDI ; The got_entry<br>
initially points here<br>
jmpq some_mcjit_funcion<br>
<br>
Then some_mcjit_funcion can extract the IR out to a new module,<br>
codegen that and set the got_entry.<br>
<br>
This also has the advantage of not requiring a large code model, even<br>
if the two functions are put far apart.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>