ORC JIT Weekly #26 -- Orc library break-up, remote TargetProcessControl, and the beginnings of a runtime.

Hi All,

I’m back again after a couple of weeks hiatus, and I have some good news for anyone interested in cross-process JITing with OrcV2: The remote TargetProcessControl and Orc library breakup patch has landed in 1d0676b54c4 [1]. Thanks very much to Dave Blaikie and Stefan Graenitz for all their feedback on the review!

As described in my last email, this commit breaks the OrcJIT library into three pieces:

  • OrcJIT retains the bulk of the code.
  • OrcTargetProcess contains code only needed by JIT execution processes, and depends only on Support.
  • OrcShared contains code required by both of these libraries – mostly RPC and error types.

For OrcV2 users who are running JIT’d code in-process the only essential change is that you will need to link against OrcTargetProcess library as well as OrcJIT. For users who want to JIT across processes/targets this library break-up means that your target process only needs to link against OrcTargetProcess, not LLVM’s core or object libraries.

This patch also introduces a pair of classes, OrcRPCTargetProcessControl and OrcRPCTPCServer, that enable Orc-RPC based out-of-process execution. These classes serve two purposes: As an example of how to build cross-process TargetProcessControl implementations (for anyone who wants to build their own based on other XPC/IPC systems), and as a way to write regression tests for out-of-process execution without introducing new dependencies into LLVM.

Anyone looking to try out the new APIs should check out llvm-jitlink, which has been updated to optionally use these new classes (see [2] for example usage). Once the API for OrcRPCTargetProcessControl settles down I plan to re-introduce Chapter 5 of the Building A JIT tutorial series to provide an introductory example for these APIs.

The next step for Orc, required for both cross-process support and new features, is a runtime library. The runtime should be loadable via the JIT like any other static library, provide support for JIT re-entry (eventually replacing the existing Orc-ABI reentry code), thread locals, eh-frame and language runtime registration, execution of initializers, and more. I’ve started a prototype of a runtime as a library within compiler-rt in the orc-runtime-prototype branch of my llvm fork [3]. There’s not much there yet, but I will keep you updated on my progress, and any questions, comments, or PRs are very welcome.

Finally: I’ve added a skeleton roadmap to the OrcV2 design document [4], and plan to keep improving the documentation. I’d love to hear any specific requests you have for documentation improvements, as this will help me focus my efforts in this area.

– Lang.

[1] https://reviews.llvm.org/D90132
[2] http://lists.llvm.org/pipermail/llvm-dev/2020-September/145070.html
[3] https://github.com/lhames/llvm-project/tree/orc-runtime-prototype
[4] https://llvm.org/docs/ORCv2.html#roadmap

Thanks for bringing this forward and sharing your ORC roadmap as well as
the Runtime drafts.

One JIT-related news from my side: The regression bug in #LLDB was fixed last week, so source-level debugging via GDB JIT Interface works again on current master when using MCJIT plus ELF object file format. The documentation update is still seeking review: Next steps will be: * Double-check with LLJITWithGDBRegistrationListener example * Consider adding a test case for LLJIT * See what it takes to allow debugging for LLLazyJIT If you have any feedback or questions on it, please let me know. Best, Stefan