<div dir="ltr">Hi Pawel,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.800000190734863px">IIRC MCJIT uses SectionMemoryManager by default.</span></blockquote><div><br></div><div>That's right, and it will use that to provide whatever functionality (memory management or symbol resolution) the user doesn't explicitly override.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.800000190734863px">Can I just provide my implementation of </span><span style="font-size:12.800000190734863px;line-height:1.5">RuntimeDyld::SymbolResolver or do I have to inherit from whole </span><span style="font-size:12.800000190734863px;line-height:1.5">SectionMemoryManager?</span></blockquote><div><br></div><div>You can just subclass RuntimeDyld::SymbolResolver and call setSymbolResolver, and let MCJIT take care of the memory management.</div><div><br></div><div>If/when you switch over to ORC you'll need to provide both a symbol resolver and memory manager with each call to addModuleSet, but for the memory manager that's usually just a case of calling llvm::make_unique<SectionMemoryManager>().</div><div><br></div><div>- Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 2, 2016 at 7:18 AM, Paweł Bylica <span dir="ltr"><<a href="mailto:chfast@gmail.com" target="_blank">chfast@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">Quick question, using MCJIT/LLVM 3.8:<div>EngineBuilder has 3 methods:</div><div><br></div><div><div> EngineBuilder &setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);</div><div><br></div><div> EngineBuilder&</div><div> setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);</div><div><br></div><div> EngineBuilder&</div><div> setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);</div></div><div><br></div><div>IIRC MCJIT uses SectionMemoryManager by default. Can I just provide my implementation of <span style="line-height:1.5">RuntimeDyld::SymbolResolver or do I have to inherit from whole </span><span style="line-height:1.5">SectionMemoryManager?</span></div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Thu, May 12, 2016 at 9:06 PM Paweł Bylica <<a href="mailto:chfast@gmail.com" target="_blank">chfast@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks!<div><br></div><div>Currently using MCJIT. But migration to ORC is on my TODO list.</div></div><div dir="ltr"><div><br></div><div>- Paweł</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, May 12, 2016 at 8:30 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Pawel,<div><br></div><div>Option (1) and (3) are very similar, but using custom resolution (option 3) guarantees that JIT'd code can't accidentally end up depending on functions in your JIT that you didn't mean to expose. Having a smaller symbol lookup space may improve performance too.</div><div>Option (2) would work, but there's no advantage vs option (3).</div><div><br></div><div>So I recommend option 3. :)</div><div><br></div><div>If you're using MCJIT you can override the findSymbol method on the MemoryManager. If you're using ORC you can pass a custom resolver to addModuleSet.</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 6:47 AM, Paweł Bylica <span dir="ltr"><<a href="mailto:chfast@gmail.com" target="_blank">chfast@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">Hi LLVM, Lang.<div><br></div><div>I'm looking for a advice here. And I truly understand very little what the relocations are and how they work.</div><div><br></div><div>The problem I want to solve is the case where a jitted code has to call back the host application to query additional data. I can think of 3 possible solutions:</div><div><ol><li>Use built-in relocation resolver (in default memory manager?) and allow the JIT to find the callback function by name. The host application needs to contain symbols that the JIT will search for. You can have only single implementation of them. The JIT will need to search in the set of all symbols in the executable.</li><li>Pass addresses of callback functions as pointers to functions to a jitted function. The generated code should use pointer to functions instead of predefined function names in calls.</li><li>Create you own Memory Manager that will provide addresses to callback functions. Because the set of callback functions is known upfront and quite small that seems to be better than 1.</li></ol><div>Can you help me to evaluate the solutions?</div></div><span><font color="#888888"><div><br></div><div>- Paweł</div></font></span></div>
</blockquote></div><br></div>
</blockquote></div></blockquote></div>
</div></div></blockquote></div><br></div>