<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Oh, I almost forgot: The "orcv1-removal-with-remote-tpc" also contains a next step towards breaking Orc up into distinct libraries.<br></div><div dir="ltr"><br></div><div>Chris Bieneman started this process on the mainline a while back by moving some of the Orc error types into a separate OrcError library (Thanks Chris!). The orcv1-removal-with-remote-tpc branch takes this further.</div><div><br></div><div>(1) It adds a new OrcTargetProcess library that contains code specific to JIT execution. E.g. runAsMain, in-process eh-frame registration code, and the OrcRPCTPCServer type.</div><div>(2) It renames OrcError to OrcShared. This will be a home for types that are shared between Orc and OrcTargetProcess. It's likely to me mostly headers, but may contain some code snippets.</div><div><br></div><div>This break-up isn't fully implemented in the branch yet: Orc still depends directly on OrcTargetProcess in places. This is just incomplete work, not by design.</div><div><br></div><div>Eventually I hope to decouple Orc (and JITLink) from ExecutionEngine entirely. With the removal of OrcV1 this should be much easier: The main changes will be a substitute types for JITTargetAddress and JITEvaluatedSymbol (we can come up with better names for them while we're at it), and moving RTDyldObjectLinkingLayer from ORC to RuntimeDyld.</div><div><br></div><div>Thoughts on the break-up (and any of the topics from the weekly mail) are very welcome.</div><div><br></div><div>Finally, correcting the typo above -- the final example should have been:</div><div><br></div><div><div><font face="monospace">target-machine% llvm-jitlink-executor listen=localhost:20000</font></div><div><font face="monospace">jit-machine% llvm-jitlink -oop-executor-connect localhost:<b>20000</b> hello-world.o</font></div><div><font face="monospace">hello world!</font></div></div><div><br></div><div>-- Lang.</div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 13, 2020 at 11:01 PM Lang Hames <<a href="mailto:lhames@gmail.com">lhames@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 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">Hi All,<div><br></div><div>Everything is landing all at once, just not in the mainline... yet.</div><div><br></div><div>As discussed in <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-September/144885.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2020-September/144885.html</a>: OrcV1 will be removed very soon. I have posted a branch with the removal, "orcv1-removal", in my llvm fork at <a href="https://github.com/lhames/llvm-project" target="_blank">https://github.com/lhames/llvm-project</a>.</div><div><br></div><div>In addition to removing OrcV1, the orcv1-removal branch also contains a prototype of the removable code feature. I'm going to discuss this at greater length over the next couple of weeks, but if anyone's interested in playing with the prototype I'd recommend starting with the <i>ResourceTracker</i> class in <a href="https://github.com/lhames/llvm-project/commit/de6f6d57d3e955b998f82ab6e610da41fcb09492" target="_blank">https://github.com/lhames/llvm-project/commit/de6f6d57d3e955b998f82ab6e610da41fcb09492</a>.</div><div><br></div><div>Finally, adding removable code unblocked another prototype I've been working on: an OrcRPC based TargetProcessControl implementation. I've added that to the "orcv1-removal-with-remote-tpc" branch at <a href="https://github.com/lhames/llvm-project" target="_blank">https://github.com/lhames/llvm-project</a>. The easiest way to start playing with this feature is via the new llvm-jitlink options: -oop-executor, and -oop-executor-connect. The -oop-executor option will fork and exec the llvm-jitlink-executor program and connect to it via open file descriptors (similar to how lli-child-target works). The -oop-executor-connect option will connect to a listening llvm-jitlink-executor process via TCP, but otherwise behaves the same. E.g.</div><div><br></div><div><font face="monospace">% llvm-jitlink -oop-executor hello-world.o</font></div><div><font face="monospace">hello world!</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">target-machine% llvm-jitlink-executor listen=localhost:20000</font></div><div><font face="monospace">jit-machine% llvm-jitlink -oop-executor-connect localhost:2000 hello-world.o</font></div><div><font face="monospace">hello world!</font></div><div><br></div><div>How all this works is left as an exercise for the reader this week. I can start providing explanations in my next update.</div><div><br></div><div>-- Lang.</div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div>