<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Bjoern,</div><div><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"><span lang="EN-GB">However... About your solution. This looks really promising – Thank you! - but sadly, I'm not experienced enough with ORC yet to understand how to use it.<br></span><span lang="EN-GB"> <br></span><span lang="EN-GB">I create a llvm::orc::LLJIT and then add my llvm::Module to it.<br></span><span lang="EN-GB">Can I use the getExecutionSession function of LLJIT to get access to this special lookup function after I added the module?</span></blockquote><p class="MsoNormal" style="color:rgb(0,0,0)"><span lang="EN-GB"><br></span></p><p class="MsoNormal" style="color:rgb(0,0,0)"><span lang="EN-GB">Yes. :)</span></p><p class="MsoNormal" style="color:rgb(0,0,0)"><span lang="EN-GB"><br></span></p><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"><span lang="EN-GB"><font color="#000000"><span>Also I have some difficulties with providing the parameters .w. For example... I don't have a "JITDylibSearchList" nor "SymbolNameSet" (I probably have it hidden somewhere). I do know those from when I do the symbol resolving. I didn't created a JITDylib for it, instead I attached a generator function to the MainJITDylib – because I have to lookup symbols from the shared memory and that list changes.</span></font></span></blockquote><p class="MsoNormal"><span lang="EN-GB"><font color="#000000"><span><br></span></font></span></p><p class="MsoNormal"><font color="#000000"><span>A JITDylib search list is a vector of (JITDylib*, JITDylibLookupFlags) pairs, where the flags indicate whether non-exported symbols should be visible to the lookup (the default is to match against exported-symbols only). A SymbolLookupSet defines the set of symbols to look up as a vector of (SymbolStringPtr, SymbolLookupFlags) pairs, where the flags tell you whether the symbol must be present (SymbolLookupFlags::RequiredSymbol, the default), or is allowed to be missing without generating an error (SymbolLookupFlags::WeaklyReferencedSymbol). In your case we can just use the defaults. Your code will look like:</span></font></p><p class="MsoNormal"><font color="#000000"><span><br></span></font></p><p class="MsoNormal"><font face="monospace"> // Get symbol names to look up. I'm assuming below that they're</font></p><p class="MsoNormal"><font face="monospace"> // already mangled and just need to be interned. If they have</font></p><p class="MsoNormal"><font face="monospace"> // not been mangled yet you will need to do that. </font></p><p class="MsoNormal"><span style="font-family:monospace"> std::vector<StringRef> SymbolNames = <symbols required>;</span></p><p class="MsoNormal"><span style="font-family:monospace"><br></span></p><p class="MsoNormal"><span style="font-family:monospace"> auto &ES = J->getExecutionSession();</span></p><p class="MsoNormal"><span style="font-family:monospace"> SymbolLookupSet LookupSet;</span></p><p class="MsoNormal"><span style="font-family:monospace"> for (StringRef Name : SymbolsNames)</span></p><p class="MsoNormal"><span style="font-family:monospace"> LookupSet.add(ES.intern(Name))</span><span style="font-family:monospace">;</span></p><p class="MsoNormal"><span style="font-family:monospace"><br></span></p><p class="MsoNormal"><span style="font-family:monospace"> auto Result = ES.lookup(</span></p><p class="MsoNormal"><span style="font-family:monospace"> { { &J->getMainJITDylib(),</span></p><p class="MsoNormal"><span style="font-family:monospace"> JITDylibLookupFlags::</span><span style="font-family:monospace">MatchExportedSymbolsOnly } },</span></p><p class="MsoNormal"><span style="font-family:monospace"> LookupSet, LookupKind::Static, SymbolState::Resolved);</span></p><p class="MsoNormal"><br></p><p class="MsoNormal">Result will now contain a map of linker-mangled symbol names (as SymbolStringPtrs) to their resolved addresses.</p><p class="MsoNormal"><br></p><p class="MsoNormal">I was going to say that you just need to send this mapping to the remote, but then I realized that that's not sufficient: You will have addresses for the symbols now, but you won't know if they're safe to access yet.</p><p class="MsoNormal"><br></p><p class="MsoNormal">How are you solving this problem in your memory-manager based solution? E.g. What if you have a cycle of dependencies: A <- B <- C <- A, with A, B and C all being provided by different processes? How do you know when any given symbol is safe?</p><p class="MsoNormal"><br></p><p class="MsoNormal">Orc has to deal with the same problem internally and handles it by maintaining a dependence graph between symbols. We could re-use this infrastructure by reflecting symbols and symbol-states between ExecutionSessions, but this would not be trivial. If possible, this is a very strong motivation for moving to a single ExecutionSession. :) </p><p class="MsoNormal"><br></p><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"><span lang="EN-GB"><font color="#000000"><span>So I'm not sure how to use it yet - sorry for the noobie question >o<</span></font></span></blockquote><p class="MsoNormal"><span lang="EN-GB"><font color="#000000"><span><br></span></font></span></p><p class="MsoNormal"><span lang="EN-GB"><font color="#000000"><span>No worries at all.</span></font></span></p><p class="MsoNormal"><span lang="EN-GB"><font color="#000000"><span><br></span></font></span></p><p class="MsoNormal"><span lang="EN-GB"><font color="#000000"><span>Cheers,</span></font></span></p><p class="MsoNormal"><span lang="EN-GB"><font color="#000000"><span>Lang.</span></font></span></p><p class="MsoNormal" style="color:rgb(0,0,0)"><span lang="EN-GB"><br></span></p><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 19, 2020 at 2:44 AM Gaier, Bjoern <<a href="mailto:Bjoern.Gaier@horiba.com" target="_blank">Bjoern.Gaier@horiba.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 lang="DE">
<div>
<p class="MsoNormal"><span lang="EN-GB">Hey Lang,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">> </span>
Thanks for your patience.<span lang="EN-GB"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">I'm happy you consider me patient x3<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">> </span>
<span lang="EN-GB">Out of interest -- Is it necessary for your JIT itself to be split across two or more processes?</span><span lang="EN-GB"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">In general I agree with your approach, but sadly - the current software design does not allow this yet. So I try understanding how to tackle both solutions - one process managing all
the modules vs multiple processes manging just there modules. I would prefer just having one process doing it, because it makes way more sense.
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">However... About your solution. This looks really promising – Thank you! - but sadly, I'm not experienced enough with ORC yet to understand how to use it.
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">I create a llvm::orc::LLJIT and then add my llvm::Module to it.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Can I use the getExecutionSession function of LLJIT to get access to this special lookup function after I added the module?<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Also I have some difficulties with providing the parameters .w. For example... I don't have a "JITDylibSearchList" nor "SymbolNameSet" (I probably have it hidden somewhere). I do know
those from when I do the symbol resolving. I didn't created a JITDylib for it, instead I attached a generator function to the MainJITDylib – because I have to lookup symbols from the shared memory and that list changes.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">So I'm not sure how to use it yet - sorry for the noobie question >o<<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Kind greetings<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Björn<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>>
<br>
<b>Sent:</b> 18 March 2020 17:26<br>
<b>To:</b> Gaier, Bjoern <<a href="mailto:Bjoern.Gaier@horiba.com" target="_blank">Bjoern.Gaier@horiba.com</a>><br>
<b>Cc:</b> LLVM Developers Mailing List <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [llvm-dev] [ORC JIT] -Resolving cross references in a multi-process scenario<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">Hi Bjoern,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">Thanks for your patience. The good news is that there is a neater way to do this: ExecutionSession's lookup methods take a orc::SymbolState parameter which describes the state that symbols must reach before a query can return (See
<a href="https://github.com/llvm/llvm-project/blob/d1a7bfca74365c6523e647fcedd84f8fa1972dd3/llvm/include/llvm/ExecutionEngine/Orc/Core.h#L1273).In" target="_blank">
https://github.com/llvm/llvm-project/blob/d1a7bfca74365c6523e647fcedd84f8fa1972dd3/llvm/include/llvm/ExecutionEngine/Orc/Core.h#L1273).In</a> your case you want to use orc::SymbolState::Resolved, which will cause the query to return as soon as the searched-for
symbols have been assigned an address.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">So if your process is generating a set of symbols that may need to be transmitted to other sessions then you would write something like:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">auto Syms = ES.lookup(SearchOrder, SymbolsToTransmit, LookupKind::Static, SymbolState::Resolved);</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">if (!Syms)</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> reportError(Syms.takeError());</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">sendSymbolsToRemote(*Syms);</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Out of interest -- Is it necessary for your JIT itself to be split across two or more processes? I had always anticipated having a single ExecutionSession attached to the target process and then running just the compilers on other processes.
That gives you a star-like IPC network with N + 1 connections: One between the execution session and each of the N compilers, and one between the execution session and the target processs. In your model it sounds like the risk is that you may end up with N(N
+ 1) IPC links with every execution session having to communicate with every other and also with the target process.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-- Lang.<u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Mar 17, 2020 at 12:34 AM Gaier, Bjoern <<a href="mailto:Bjoern.Gaier@horiba.com" target="_blank">Bjoern.Gaier@horiba.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span lang="EN-GB">Hello LLVM-Mailing-List and Lang,</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">I played around with this problem a bit and found a way of doing this – however I’m not sure about the consequences and if this is really a good idea.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">I went trough all of the global symbols and functions being defined in the llvm::Module and set for each of them a new section name (based on there name). With
this approach the memorymanager could tell me already the addresses of my symbols, which I could then share with the other process. However, this approach needed to load the module two times, first to get the future address and in a second run to use the addresses
to resolve the symbols.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">The only disadvantage I noticed so far was that the overall size of the emitted code was bigger then having the regular sections. Are there any other risks I
might have overseen? </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">Kind greetings</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">Björn</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<div>
<div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>>
<b>On Behalf Of </b>Gaier, Bjoern via llvm-dev<br>
<b>Sent:</b> 06 March 2020 14:24<br>
<b>To:</b> LLVM Developers Mailing List <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>><br>
<b>Subject:</b> [llvm-dev] [ORC JIT] -Resolving cross references in a multi-process scenario</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">Hello LLVM-Mailing-List and Lang,</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">I have a very weird (or strict?) scenario and was curious if the ORC JIT can help me with it. Soo here it comes:</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">I have currently a windows process ("Runtime") which does nothing but creating a shared memory with read, write and execute rights - and also writing some function
addresses like from printf to it. </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">Then I have two or more processes which are using the ORC JIT to load modules to this shared memory, in "perspective" of the process I mentioned above ("Runtime").
The sections are remapped from the other processes to be correct for "Runtime", also they resolve the undefined references for "Runtime" - like for printf and so on.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">This works quite well so far! Wuhuhu x3</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">However, there is one issue about it. Given that those two (or more processes) are now loading modules that reference each other. Like Module A is using a function
of Module B - but Module B also uses a function of Module A. How could I resolve those modules when they are loaded from different processes? Normally I would use llvm-link to link those modules but in my current scenario this is sadly not possible.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">Can the ORC JIT help me with that? Can I solve this problem differently? Like replacing all the functions of Module A that rely on Module B with function pointers?
Is something like that possible?</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">I know this situation is pretty uncommon but sadly I ran into that issue.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">Kind greetings</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB">Björn</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><u></u><u></u></p>
<p class="MsoNormal">Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode, Heiko Lampert,
Takashi Nagano, Takeshi Fukushima. Junichi Tajika <u></u><u></u></p>
</div>
<p class="MsoNormal">Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima. Junichi Tajika
<u></u><u></u></p>
</div>
</blockquote>
</div>
</div>
Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima. Junichi Tajika
</div>
</blockquote></div></div></div></div></div></div></div></div></div></div></div></div></div>