Description of the project: JITLink is LLVM’s new JIT linker API – the low-level API that transforms compiler output (relocatable object files) into ready-to-execute bytes in memory. To do this JITLink’s generic linker algorithm needs to be specialized to support the target object format (COFF, ELF, MachO), and architecture (arm, arm64, i386, x86-64). LLVM already has mature implementations of JITLink for MachO/arm64 and MachO/x86-64, and a relatively new implementation for ELF/x86-64. Write a JITLink implementation for a missing target such as PowerPC or BPF. If you choose to implement support for a new architecture using the ELF or MachO formats then you will be able to re-use the existing generic code for these formats. If you want to implement support for a new target using the COFF format then you will need to write both the generic COFF support code and the architecture support code for your chosen architecture.
Expected result:
Write a JITLink specialization for a not-yet-supported format/architecture
such as BPF or PowerPC.
Desirable skills:
Intermediate C++; Understanding of LLVM and the LLVM JIT in particular;
familiarity with your chosen format/architecture, and basic linker concepts
(e.g. sections, symbols, and relocations).
Though I’m interested in this project(not determined to write a proposal for this project), I’m a bit confused.
Are you using the term BPF as “classical BPF(cBPF)” or “extended BPF(eBPF)”?
I just want it to be clear. Thanks!
Hi,
I would be interested in the project working on Backend development. I have worked on SelectionDAG extension with TableGen and would love to contribute to JITLink backend space.
Thanks for reaching out! I suspect you already have a good idea in that area. If not please feel free to ask concrete questions which can help you write a solid proposal.
Hi all, sorry for having missed to reply in this thread so far. It would be great to review your proposals. Please PM me if you want to share yours!
@Eymay If you managed to work on the LLVM codegen backends, I think you could succeed in this project as well. However, please note: JITLink backends are not to be confused with the codegen backends in LLVM. These produce architecture-specific machine code from LLVM IR. JITLink uses their output and does in-memory linking and loading. This typically involves things like relocation resolution, registration of exception handlers and TLS handling. In case you choose AArch32, I am happy to review your proposal. My minimal implementation might be a good starting point and it’s full of low-level questions!
@diohabara Great to see interest the BPF one! This one is a bit special actually. Since the output runs in a VM, the classical part is likely much easier (e.g. there are only a few relocations to support). The research question is how to set up testing for this:
We need a userspace executor the includes VM and verifier. While there are existing options for the VM, the only existing verifier is the one in the Linux kernel (AFAIK). However, this very recent post looks promising: Harnessing the eBPF Verifier | Trail of Bits Blog
Can we teach the VM to accept incremental updates for a program? This one is outside my eBPF knowledge, but my gut feeling is that we can teach it to do so.
@vvassilev Thank you for your information! I’ll look for your email addresses or accounts!
@weliveindetail Thank you for the concrete example. Overthinking will not lead to good results, so I would like to ask you to look at the draft at this point and work with us to improve it. I’ll send it soon!
