This talk covers the ongoing effort about adding eBPF support to the GNU Toolchain. eBPF is a virtual machine running within the Linux kernel; initially intended for user-level packet capture and filtering, eBPF has since been generalized to also serve as a general-purpose infrastructure for non-networking purposes.

Binutils support is already upstream [1]. This includes a CGEN cpu description, assembler, disassembler and linker. By the time of the conference a simulator will be available as well, along with GDB support. A GCC backend will be submitted for inclusion upstream before September.

The first part of the talk will be a brief general description of the project, its components, what motivated us to start working on it, and an update on the project's status at the time of the conference.

Then we will discuss the particular challenges of supporting a target like eBPF:

On one hand, the kernel virtual machine has some unique characteristics that have a definitive impact on the tooling, like the in-kernel validator and the specialized contexts in which eBPF programs run. We will show how the tools can help improving the eBPF programmer's experience.

On the other hand, the exact shape of compiled eBPF code is still subject to change, and is in fact rapidly changing and evolving. Initially quite simple in terms of toolchain needs (single compilation units, no linking) this is changing as more kernel systems are being changed/written to be based on eBPF, and as the in-kernel validator is becoming more and more sophisticated. Along with bigger and more complex programs comes the need for more abstraction, hence modularity and code reuse. Kernel hackers are already discussing about bpf-to-bpf calls, run-time linking, and so on. This increased level of ambition and sophistication imposes additional requirements on the tools.

Finally, interoperability with clang/llvm (the other available toolchain supporting eBPF) will be also discussed, in the more general context of ABI and conventions for compiled eBPF, which are still to be (well) defined and documented.

[1] https://sourceware.org/ml/binutils/2019-05/msg00306.html