<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Christian, Stefan,<div><br></div><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">(1) How do I take ownership of the ObjectFile once the ORC JIT has created it?<br> I'd like to take ownership of object files generated by the ORC JIT so that I can save them to disk and in later sessions reload them.</blockquote><div><br></div><div>It depends on whether you are writing a custom JIT class or using LLJIT.</div><div><br></div><div>If you are writing a custom JIT class: At the moment the best way to do this is with an ObjectCache attached to your IR compiler (see llvm/ExecutionEngine/Orc/CompileUtils.h). This makes it easy to build an association between an IR input file and a compiled object file. In the future I plan to add an additional notification callback to RTDyldObjectLinkingLayer which can be used to transfer ownership of loaded objects back to the client.</div><div><br></div><div>If you are using LLJIT: There is no way to do this yet, but I plan to add support for ObjectCaches. Let me know if you are using LLJIT and I can do this straight away (it is an easy change). </div><div><br></div><div>(2) How would I pass an ObjectFile saved in question#1 back to ORC so that it will relocate it and generate function pointers?</div><div><br></div><div>You can add an object file directly to the RTDyldObjectLinkingLayer of your JIT class using that class's add method.</div><div><br></div><div>If you are using an ObjectCache with LLJIT (once that is supported), and assuming the ObjectCache implements the getObject method, then the object will be loaded automatically when you attempt to compile the source IR for that object. If you wish to use the ObjectCache to save the object only and manage the caching outside the ObjectCache then you can use LLJIT::addObject to add the saved object.</div><div><br></div><div>(3) How do I get access to the relocated ObjectFile sections?</div><div>(4) For the "__llvm_stackmaps" section - will I need to do any relocation to obtain the function pointers?</div></div><div><br></div><div>Looks like you already figured this one out. :)</div><div><br></div><div>To confirm: You will want to call the base class finalizeMemory method. You can do that before or after running your code: finalizeMemory will not change section contents, but will generally apply memory protections. Since this is a data section it should remain readable either way.</div><div><br></div><div><br></div><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">However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2):<br>/// Sending relocatable objects to the server (rather than fully relocated<br>/// bits) allows JIT'd code to be cached on the server side and re-used in<br>/// subsequent JIT sessions.</blockquote></div><div><br></div><div> Actually I want to kill off the RemoteObjectLayer (at least as it is currently implemented). There are better solutions to the Remote JITing problem in the new API. :)</div><div><br></div><div>-- Lang.</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 5, 2018 at 12:19 PM Stefan Gränitz <<a href="mailto:stefan.graenitz@gmail.com" target="_blank">stefan.graenitz@gmail.com</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 bgcolor="#FFFFFF">
Hi Christian<br>
<br>
Your use case seems to have similar requirements as remote JITing in
ORC. So far I haven't used that part myself and I am sure Lang can
tell you much more about it. However, this comment on the
RemoteObjectClientLayer class sounds promising for your questions
(1) and (2):<br>
<br>
/// Sending relocatable objects to the server (rather than fully
relocated<br>
/// bits) allows JIT'd code to be cached on the server side and
re-used in<br>
/// subsequent JIT sessions.<br>
<br>
There are a few tests here that illustrate its usage:<br>
<a class="m_6900262629572111906gmail-m_-2708247928901434380moz-txt-link-freetext" href="https://github.com/llvm-mirror/llvm/blob/master/unittests/ExecutionEngine/Orc/RemoteObjectLayerTest.cpp" target="_blank">https://github.com/llvm-mirror/llvm/blob/master/unittests/ExecutionEngine/Orc/RemoteObjectLayerTest.cpp</a><br>
<br>
Note that it still uses LegacyJITSymbolResolver, so I guess it may
change any time soon.<br>
<br>
Hope it helps for the time being.<br>
Cheers, Stefan<br>
<br>
<div class="m_6900262629572111906gmail-m_-2708247928901434380moz-cite-prefix">Am 05.11.18 um 19:44 schrieb Christian
Schafmeister via llvm-dev:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I think I found the answer to #3 and #4.
<div>(a) I overloaded the
SectionMemoryManager::finalizeMemory(...) method. </div>
<div>(b) I first call the base classes method (maybe not
necessary).</div>
<div>(c) At this point the __llvm_stackmaps section that I saved
in thread local memory when allocateDataSection was called
appears to be fully set up and relocated.</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Mon, Nov 5, 2018 at 12:36 PM Christian
Schafmeister <<a href="mailto:meister@temple.edu" target="_blank">meister@temple.edu</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">
<div dir="ltr">
<div>I have a few questions about the new ORC JIT.</div>
<div><br>
</div>
<div>I saw Lang Hames (hi!) excellent talk at the llvm-dev
meeting a few weeks ago. The ORC JIT is undergoing some
API changes and I'd like/need to take advantage of them.</div>
<div><br>
</div>
<div>(1) How do I take ownership of the ObjectFile once
the ORC JIT has created it?</div>
<div> I'd like to take ownership of object files
generated by the ORC JIT so that I can save them to disk
and in later sessions reload them.</div>
<div>(2) How would I pass an ObjectFile saved in
question#1 back to ORC so that it will relocate it and
generate function pointers?</div>
<div>(3) How do I get access to the relocated ObjectFile
sections?</div>
<div> Currently I subclass SectionMemoryManager and
implement allocateDataSection(...)</div>
<div> I can get the memory for the "__llvm_stackmaps"
section - but I don't know when/if the contents have
been fully set up with relocated function pointers.</div>
<div>(4) For the "__llvm_stackmaps" section - will I need
to do any relocation to obtain the function pointers?</div>
<div><br>
</div>
<div>Background:</div>
<div>I'm using llvm.experimental.stackmaps to register one
variable in each stack frame that contains spilled
register arguments.</div>
<div>I've figured out how to get access to the stackmaps
for code that I load into my system from dynamic
libraries that our compiler generates.</div>
<div>The answers to questions above will help me get
access to the stackmaps from ORC JITted code.</div>
<div><br>
</div>
-- <br>
<div dir="ltr" class="m_6900262629572111906gmail-m_-2708247928901434380m_5097034966196357672gmail_signature">
<div dir="ltr">
<div style="font-size:small">Christian Schafmeister</div>
<div style="font-size:small">Professor, Chemistry
Department</div>
<div style="font-size:small">Temple University</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="m_6900262629572111906gmail-m_-2708247928901434380gmail_signature">
<div dir="ltr">
<div style="font-size:small">Christian Schafmeister</div>
<div style="font-size:small">Professor, Chemistry Department</div>
<div style="font-size:small">Temple University</div>
</div>
</div>
<br>
<fieldset class="m_6900262629572111906gmail-m_-2708247928901434380mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
LLVM Developers mailing list
<a class="m_6900262629572111906gmail-m_-2708247928901434380moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_6900262629572111906gmail-m_-2708247928901434380moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="m_6900262629572111906gmail-m_-2708247928901434380moz-signature" cols="72">--
<a class="m_6900262629572111906gmail-m_-2708247928901434380moz-txt-link-freetext" href="https://weliveindetail.github.io/blog/" target="_blank">https://weliveindetail.github.io/blog/</a>
<a class="m_6900262629572111906gmail-m_-2708247928901434380moz-txt-link-freetext" href="https://cryptup.org/pub/stefan.graenitz@gmail.com" target="_blank">https://cryptup.org/pub/stefan.graenitz@gmail.com</a></pre>
</div>
</blockquote></div></div></div></div></div>