BPF support in GCC 16 and beyond [LWN.net]

LWN<br>.net<br>News from the source

Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments

LWN FAQ<br>Write for us

Edition Return to the Front page

User:<br>Password: |

Log in /<br>Subscribe /<br>Register

BPF support in GCC 16 and beyond

[LWN subscriber-only content]

Welcome to LWN.net

The following subscription-only content has been made available to you<br>by an LWN subscriber. Thousands of subscribers depend on LWN for the<br>best news from the Linux and free software communities. If you enjoy this<br>article, please consider subscribing to LWN. Thank you<br>for visiting LWN.net!

By Daroc Alden<br>May 21, 2026

LSFMM+BPF

José Marchesi and the GCC-BPF developers opened the BPF track at the 2026

Linux Storage,<br>Filesystem, Memory-management, and BPF Summit<br>with a 90-minute summary of what has changed for GCC's BPF support in the past year.<br>This kind of session has become something of a tradition. There were similar<br>updates in

2025 and

2024. This time around, GCC seems to be closing in on<br>feature parity with the LLVM toolchain — as the slides detail.

Usually, when the GCC-BPF developers come to conferences, they present for an hour, ask some<br>questions, and that's the end of the discussion, Marchesi said. He wanted to do<br>better this year, promising to remain reachable throughout the conference. He<br>wanted to use the conference to discuss the remaining handful of fixes needed for GCC<br>to pass the kernel's BPF self-tests, which were detailed in the latter half of<br>the talk.

There is now BPF support across the GNU toolchain, Marchesi continued. GCC, of<br>course, but also projects like

binutils,

DejaGNU,

GNU poke,<br>and even

GDB support BPF. Some of that "support" has not quite been kept up to<br>date, however. GDB's BPF simulator, for example, is not used much and so has fallen<br>out of date. That said, the other components of the toolchain are<br>making good progress.

GCC 16.1 was

released on April 30. That was the first release to feature work from<br>Vineet Gupta, who joined the GCC-BPF team recently and is "already making the<br>rest of us look bad" with the quality of his contributions. There is also now a<br>BPF-specific GCC mailing list, bpf@gcc.gnu.org, and a<br>weekly meeting

on the Software Freedom Conservancy's BBB instance on Mondays.<br>"It's fun. We have fun. If you are bored, Monday ..."

Meanwhile, GCC is now able to pass an increasing number (601 of 5488)<br>[Faust wrote in to explain that I was mis-reading the output of the self-tests,<br>and that it is actually 601 tests out of 713, comprising 5488 sub-tests.] of the<br>kernel's BPF self-tests. Lots of the remaining problems apply to a large number<br>of tests, Marchesi said, so it's a relatively small set of things to fix to make<br>the self-tests pass. Even before that point, though, GCC does work to compile<br>many of the simple BPF programs used by systemd. Some distributions, such as<br>Gentoo, use GCC as their default BPF compiler, which is great because it means<br>that the GCC developers receive actual bug reports.

GCC also has some work-in-progress support for the variant of BPF used by

Solana<br>— a blockchain project that uses BPF for on-chain contracts. "I don't<br>understand a lot about those things," Marchesi admitted. He also wasn't sure<br>why they were using a modification of BPF. But, since they are, it provides an opportunity to steal<br>some of their ideas. For example, Solana has 64-bit product, quotient, and<br>remainder instructions that might be worth incorporating into BPF proper.

Other convenience features of GCC have also seen progress. GCC now generates<br>line information for BPF programs, so verifier diagnostics can reference<br>specific lines. Gupta has been working on some ABI bugs, and there are various<br>fixes to the code-generation logic, Marchesi said. In particular,<br>memmove() and memset() are now inlined properly.

"Compile once — run everywhere" (CO-RE) relocations, which posed a problem for<br>GCC last year, have continued to be troublesome. Eventually, the GCC team<br>decided to just implement the same support for pushing and popping attribute<br>pragmas that Clang uses to support the feature. "We've had enough. So, we're<br>going to implement those, if only for structs."

As GCC comes closer to passing the kernel's BPF self-tests, the team has also<br>added BPF tests to GCC's test suite, Marchesi said. The BPF support in the<br>DejaGNU testing framework (added by Piyush Raj) has been helpful for that; now, running make<br>check in the GCC repository will automatically download and compile an appropriate kernel,<br>run it in a virtual machine, and use it to run a selection of BPF tests. GCC<br>developers working on other areas of the toolchain don't need to know anything<br>about BPF in order to test it.<br>Hopefully, this should ensure that unrelated changes to GCC don't affect the<br>verifiability of the BPF bytecode it generates.

In response to a question from the audience, Gupta clarified that these tests<br>are run as part of GCC's...