<div dir="ltr">Hi Axel,<div><br></div><div>You could use multiple MCJIT instances, each with its own RTDyldMemoryManager instance. That would allow you to selectively finalize memory.<br></div><div><br></div><div>Alternatively you could avoid finalizing the inner MCJIT (I don't think that's necessary for resolving symbols), and defer the initializer calls until after you've finalized the outer one?</div><div><br></div><div>Possibly of interest: I came across the same problem while working on the new Orc APIs, and there I opted for a version of the first solution: Each Module actually gets its own RTDyldMemoryManager instance, so they can be finalized independently.</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 22, 2015 at 9:25 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+Lang, owner of JITs</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 22, 2015 at 6:05 AM, Axel Naumann <span dir="ltr"><<a href="mailto:Axel.Naumann@cern.ch" target="_blank">Axel.Naumann@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I ran into a problem migrating cling (finally!) to MCJIT: When an<br>
("outer") MCJIT's finalization /<br>
llvm::RuntimeDyldImpl::resolveExternalSymbols() is called and a symbol<br>
is not known, cling can help by loading the suitable library and<br>
providing the symbol.<br>
<br>
It compiles the relevant C++ header as part of loading the library. This<br>
compilation emits symbols through the MCJIT. That "inner" MCJIT'ing then<br>
needs to finalize to resolve its symbols and to run the initializers. My<br>
problem is that this also finalizes the outer MCJIT, e.g. marking *all*<br>
memory pages as non-writable + executable - which in turn makes the<br>
outer MCJIT bomb as soon as it tries to write the newly determined<br>
relocation address to (now protected) memory.<br>
<br>
Here is what I guess I'm looking for:<br>
- outer resolveExternalSymbols() has a missing symbol,<br>
- we compile and emit into a new "memory section"<br>
- we finalize only that section<br>
- we run static init of that secion<br>
- we pass that now resolved symbol address to the outer MCJIT.<br>
<br>
I tried to have the LinkingMemManager's ClientMM stack memory managers<br>
upon recursion, so each of them can operate on their own memory regions.<br>
But that seems to mess up the section counts / symbol offset tables :-(<br>
<br>
What would you recommend me to do?<br>
<br>
Cheers, Axel.<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>