Progress toward compiling Linux with gccrs [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

Progress toward compiling Linux with gccrs

[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!

July 28, 2026

This article was contributed by Arshal Aromal

The<br>gccrs project, which is creating a Rust frontend for the GCC compiler, has<br>spent the first half of 2026 focusing on compiling the Linux<br>kernel. By testing the compiler against the kernel crates, the<br>development team has made significant progress toward generating correct code<br>for other Rust programs. As detailed in the project's

weekly and

monthly reports, this effort has uncovered and resolved problems<br>in areas such as<br>attribute handling (described in the

report for February), name resolution, and resource management (both

detailed in the May report). Currently, the compiler can only handle simple<br>standalone programs, but that situation could change rapidly in the coming<br>months.

The drive to compile the Rust components of the Linux kernel stems from the new<br>toolchain requirements brought by Rust's introduction into the kernel.<br>Currently, developers must use the LLVM-based rustc compiler (although<br>rustc does have experimental, in-progress support for using GCC as a backend via

rust_codegen_gcc). While<br>LLVM is supported by the kernel, a GCC-based alternative is necessary to support architectures not<br>targeted by LLVM and to integrate with GCC's existing plugin ecosystem. As the<br>kernel's Rust integration matures, toolchain flexibility and the availability of<br>a GCC-based compiler have become priorities for Linux distributions.

Reorganizing milestones

Compiler frontend projects often track their progress against the release<br>cycle of their target backend. In its March<br>2026 report, the gccrs team announced a change in<br>project management, opting to organize its work into three<br>capability-based milestones rather than targeting specific GCC<br>versions.

The first milestone is an "embedded Rust compiler" capable of<br>compiling

no_std programs that depend only on the

core crate. The second is a "Rust for Linux compiler" that<br>supports the

alloc crate alongside the specific crates used<br>by the kernel. The final milestone is a "general purpose compiler" aimed<br>at handling broader Rust applications beyond the kernel environment.

The first milestone is not completely implemented, but it is close.<br>Progress toward the Rust for Linux milestone is underway. In March, the team<br>added support for compiler_builtins,<br>a key low-level crate required by kernel builds, and focused on<br>resolving problems within the kernel's ffi crate. To<br>support this effort, Zhi Heng joined the project in May<br>2026 for an Open Source Security<br>internship. His work is dedicated to fixing bugs encountered when<br>gccrs compiles kernel crates and establishing<br>continuous-integration testing to prevent regressions.

However, simply testing to ensure the compiler can process Rust code<br>without crashing is only part of the task. The generated code must also<br>be correct. The implementation of Rust's destructor semantics is key to the<br>generation of correct code, because idiomatic Rust code uses<br>them more heavily than traditional C code, so that has been another area of focus.

The Drop infrastructure

Rust manages resources using a scope-based model known as resource<br>acquisition is initialization (RAII). When a value goes out of<br>scope, the compiler automatically inserts a call to its destructor,<br>which is defined by the Drop<br>trait.

In Rust, tracking when variables must be cleaned up is complex<br>because a variable's initialization state can change depending on the<br>control flow within a function. If a variable is conditionally moved or<br>only partially initialized, the compiler cannot simply drop it at the end of the<br>enclosing scope. To solve this, the frontend must analyze the<br>control-flow graph and generate dynamic "drop flags"—boolean variables<br>tracked at run time—to record whether a value needs to be destroyed<br>before passing this representation to the GCC backend. That analysis was missing<br>from the initial implementation of Drop in gccrs, causing some<br>Drop::drop() calls to be omitted or incorrect.

In the context of the Linux kernel, missing Drop calls<br>lead to severe run-time failures, such as memory leaks or unreleased<br>system resources. A primary example is lock management. When kernel code<br>acquires a lock, the Rust for Linux API returns a<br>MutexGuard. The Drop implementation for this<br>guard is responsible for releasing the lock.

As the team...