Oracle introduces patch series to add eBPF support for GCC

Yesterday, the team at Oracle introduced a patch series that brings a port of GCC to eBPF (extended Berkeley Packet Filter), a virtual machine that is placed in the Linux kernel. With the support for binutils (binary tools), this port can be used for developing compiled eBPF applications.

eBPF was initially used for capturing user-level packet and filtering, it is now used to serve as a general-purpose infrastructure for non-networking purposes as well.

Since May, Oracle has been planning on introducing an eBPF back-end to GCC 10 to make the GNU compiler target the general-purpose in-kernel virtual machine. Oracle’s inclination on bringing in the eBPF support for GCC is part of the company’s efforts towards improving DTrace on Linux.

As a compilation target, eBPF is different because of the restrictions imposed by the kernel verifier, and due to the security-driven design of the architecture.

Currently, the back end issues an error whenever an eBPF restriction is violated.  This increases the chances of the resulting objects to become acceptable by the kernel verifier, hence shortening the development cycle.

How will the patch series support GCC?

• The first patch in the series updates config.guess and config.sub from the ‘config’ upstream project to recognize bpf-*-* triplets.
• The second one fixes an integrity check in the opt-functions.awk.
• The third patch in the series annotates multiple tests in the gcc.c-torture/compile test suite.
• While the fourth one introduces a new target flag named as indirect_call and annotates the tests in gcc.c-torture/compile.
• The fifth patch in the series adds a new GCC port.
• The sixth one adds a libgcc port for eBPF, currently, it addresses the limitations that are imposed by the target, by eliminating a few functions in libgcc2 whose default implementations surpass the eBPF stack limit.
• While the seventh, eighth and ninth patches are involved in dealing with testing the new port. The gcc.target testsuite has been extended with eBPF-specific tests that cover the backend-specific built-in functions as well as diagnostics.
• The tenth one adds documentation updates including information related to the new command-line options and compiler built-ins to the GCC manual.

Jose E. Marchesi, software engineer at Oracle writes, “Finally, the last patch adds myself as the maintainer of the BPF port. I personally commit to evolve and maintain the port for as long as necessary, and to find a suitable replacement in case I have to step down for whatever reason.”

Other improvements expected in the port

Currently, the port supports only a subset of C, in future, the team might add more languages as the eBPF kernel verifier gets smarter. Dynamic stack allocation (alloca and VLAs) is achieved by using a normal general register, %r9, as a pseudo stack pointer. But it has a disadvantage that makes the register “fixed” and therefore not available for general register allocation.  

The team is planning to bring more additions to the port that can be used to translate more C, CO-RE capabilities (compile-once, run-everywhere), generation of BTF, etc.

The team is working on simulator and GDB support so that it becomes possible to emulate different kernel contexts where eBPF programs execute. Once the support for simulator is achieved, a suitable board description will then be added to DejaGnu, GNU test framework that would run the GCC test suites on it.

Now there will be two C compilers that will generate eBPF so the interoperability between programs generated by the compilers will become a major concern for the team. And this task would require communication between the compiler and the kernel communities.

Users on HackerNews seem to be excited about this news, a user commented, “This is very exciting! Nice work to the team that’s doing this. I’ve been waiting to dive into eBPF until the tools mature a bit, so it’s great to see eBPF support landing in GCC.”

To know more about this news, check out the official mail thread.

Other interesting news in programming

Core Python team confirms sunsetting Python 2 on January 1, 2020

Developers from the Swift for TensorFlow project propose adding first-class differentiable programming to Swift

Go 1.13 releases with error wrapping, TLS 1.3 enabled by default, improved number literals, and more