Compiling the kernel with gccrs

Pierre-Emmanuel Patry and Arthur Cohen gave a talk at RustConf 2026 on the status of the Rust frontend for GCC (gccrs), with a particular eye toward the goal of compiling the Linux kernel. Patry gave a follow-up talk for a more kernel-focused audience at Kangrejos the next week, which Cohen could not attend. The gccrs project is making good progress overall, but it will still be some time until the compiler is usable.

Cohen began the RustConf talk by stating that the title of the presentation, "Compiling the Linux kernel with gccrs", was a lie. Gccrs cannot currently compile the Linux kernel, for multiple reasons. One such reason, Cohen said, is that he and Patry were laid off and couldn't dedicate all of their time to gccrs — although Open Source Security has since picked up their contracts. Another reason, which Patry brought up at Kangrejos, was that their current goal was really to "miscompile the Linux kernel". The project needs to get to the point of emitting a binary that can be tested and validated to be said to be "compiling" anything; almost certainly, there will be a delay between the point where gccrs accepts the kernel's Rust code without complaint, and where the output it produces is actually a usable kernel. Nevertheless, the two of them have made substantial progress.

GCC is a nearly 40-year-old project, Cohen explained, that brings together compilers for a number of different languages, such as C, C++, Fortran, Go, and Algol. The gccrs project wants to add a full implementation of a Rust compiler to that list, separate from the Rust project's rustc compiler. That is important for many reasons. For example, GCC supports more backend architectures than rustc does. GCC also supports custom compiler plugins that many existing projects rely on. With Rust code now included in the Linux kernel, it would be nice to be able to compile the kernel with just GCC.

Therefore, the main goal of gccrs has been to compile the Rust code present in the Linux kernel. That code is split into several different crates that depend on each other, Patry explained to both the RustConf and Kangrejos audiences. The most fundamental is core, which provides the "bare minimum to make Rust language features work". For example, for loops in Rust use the Iterator trait, which is defined in core. Without core, the compiler can't support for loops.

Other crates within the kernel include stdarch, which provides architecture-specific operations, alloc, which handles memory allocation, pin_init, which handles creating immovable structures, and others. When gccrs started, Patry said, he and Cohen began by trying to compile small snippets of Rust code in isolation. That approach has reached its limits, so the plan now is to focus on making core work, and then move up the dependency graph to alloc and so on, until the whole kernel compiles.

That approach has been working well, but has caused some problems with trying to parallelize the work, Cohen said. Currently, each problem that comes up with compiling core is hidden behind the previous problem, making it hard to split work across multiple contributors. To address that, Patry and Cohen made a mock version of the core library with only the parts needed by alloc, so that getting that crate to compile could proceed in parallel.

The core library is "really complicated", Cohen added. In many ways, it is the strangest Rust library, since it needs to do so many low-level operations that other code doesn't need to address. The hope is that once gccrs can compile core, it will be able to handle most Rust code, and any remaining libraries will be easy to support. "Maybe I just tell myself that," Cohen added, to general chuckles. The alloc crate also uses some complicated features, such as arbitrary self types, but the version used in the kernel is simpler than the one used in the standard library, so Cohen is not too worried.

The project will eventually need to get the standard-library version working, however. There are two kernel crates that use procedural macros, Patry said, which are Rust code that is called during the compilation process, and can link against the standard library. So, even though the kernel itself does not link the standard library, gccrs will still need to be able to build it in order to compile the kernel.

At Kangrejos, Miguel Ojeda asked whether it would be possible to use procedural macros compiled by rustc, as a temporary workaround until the standard library is usable. Patry wasn't sure, but thought that it was theoretically possible. He was leery of disrupting the ecosystem by introducing strange incompatibilities between procedural macros and the code they generate, however. Ojeda opined that a workaround that gave the kernel access to gccrs a bit earlier would be useful for testing gccrs and finding problems. He then went to check on the use of the standard library in procedural macros in the kernel, and reported a few minutes later that the only uses are via the syn crate, and a single use of a BTreeSet that could probably be replaced.

Gary Guo thought that Ojeda was overlooking the complexity needed to support allocation, however, which is used implicitly by procedural macros. Once allocation is working, "you probably also get B-Trees for free," he remarked. Patry said that he hadn't spent much time looking into getting procedural macros working, since he and Cohen had been focused on the core crate. Maybe some additional thought will find a way to make it work, he suggested.

Compiling core

Cohen went into more detail on what has been involved in getting core to compile. For the past three years, he and Patry have mostly been working on fixing name resolution, the process of linking uses of names to their definitions. The initial implementation was simple, "like how a textbook compiler does name resolution". That implementation proved to be fundamentally flawed, however, because Rust's name resolution is quite complex. There are multiple separate namespaces (for functions and constants, types, labels, and lifetimes), and name resolution sometimes has to cross between them. Additionally, names can be used before they are defined.

Names can also be defined by macros, which themselves rely on being able to resolve names. Therefore, name resolution and macro expansion have to run interleaved with each other, in a fix-point fashion that repeats the process until all names have been discovered. Cohen originally told his boss that this work would take three weeks. Patry and Cohen finished it just before RustConf, nearly three years later. Despite the delays, name resolution is now working correctly, as is declarative macro expansion. It is not particularly fast, but "that is a problem for future Arthur".

At Kangrejos, Patry went into more detail on the performance problem. The core crate is roughly 85,000 lines of code, and gccrs used to take about 42 minutes to compile it. The crate does rely heavily on macros, but most of the time is spent in name resolution. Because name resolution runs until it reaches a fix-point, the compiler makes many of the same calls. Adding a cache for those calls brought the time required to compile core down to three minutes (compared to rustc's 30 seconds), which is "not as fast as rustc, but fast enough to work with".

The other tricky parts, such as inline assembly support, and the lang items system, are mostly working. At this point, each individual bug that the gccrs developers work on could be the last one standing between gccrs and compiling core.

There is still a known problem with passing crate metadata between compilation units, Patry added. Right now, the serialization format for crate metadata is a dump of the crate's abstract syntax tree. That's a temporary hack, he explained, which is working for the moment but that will need to be cleaned up to do cross-crate linking correctly.

Next steps

Cohen then explained some of the next steps for the project. Another known problem is the handling of the Drop trait, which is used to automatically clean up allocations at the end of their scope. Janet Chien, a Google Summer of Code (GSoC) participant working with the gccrs project, has been focused on improving that part of the implementation. When she started work, gccrs did not implement drops at all. Now, it has support for common cases, but can still be tripped up by nonlinear control flow, partial moves, generics, and temporary values. Enes Çevik, another GSoC participant, has been adding infrastructure for compiling and testing the alloc crate.

Once gccrs can compile all of the crates used by the kernel, the next step will be to catch up to stable Rust. For the last several years, gccrs has been targeting parity with rustc version 1.49 and a matching old version of the kernel. The project chose to do that to avoid chasing an endlessly moving target while trying to get basic functionality working at all; eventually, however, it will be time to chase that target. Patry is not too worried about the process of catching up. Most changes to the language come in the form of new library functions and types, and stabilization of existing unstable features, which Cohen expects should be trivial to support.

There are three features in particular that do represent actual changes to the language itself that will have to be dealt with, which Patry called out for the RustConf audience: trait upcasting, the new use<...> syntax, and return-position impl Trait in traits. There is also one additional experimental feature, cfi_encoding, which the kernel uses when generating bindings between C and Rust code. That will be slightly tricky, Patry explained, because it requires changes to GCC's control-flow integrity (CFI) code. There is an existing patch series addressing that, but it has remained unmerged since its introduction in 2025. The gccrs developers may need to work with the rest of the GCC maintainers to figure out whether that series is acceptable and how to get it merged.

After that, the project will have to test kernels compiled with gccrs to ensure that the behavior exactly matches that of binaries compiled with rustc. Since the kernel is not even compiling yet, Patry and Cohen haven't begun major work in that direction, but they have taken a few preliminary steps.

One audience member at RustConf asked whether gccrs implemented any of the intermediate representations that rustc uses. Patry said that it did not — although since the project hopes to reuse the implementation of the next-generation trait solver, the code may eventually have to produce an intermediate representation suitable for that.

Another person asked how well documented the Rust language specification is, and how that affected the validation of gccrs. The specification is not enough to fully implement a compiler, Cohen said, but that isn't the fault of the people working on the specification. The upstream rustc developers are productive, with new features coming with each version of the compiler. Patry and Cohen have tried to improve the specification where it is lacking, which is another benefit of having an independent reimplementation of the language.

[ Thanks to the Linux Foundation, LWN's travel sponsor, for assistance with attending both RustConf and Kangrejos. ]