Progress toward compiling Linux with gccrs

使用 gccrs 编译 Linux 的进展

The gccrs project, which is creating a Rust frontend for the GCC compiler, has spent the first half of 2026 focusing on compiling the Linux kernel. By testing the compiler against the kernel crates, the development team has made significant progress toward generating correct code for other Rust programs. As detailed in the project’s weekly and monthly reports, this effort has uncovered and resolved problems in areas such as 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 standalone programs, but that situation could change rapidly in the coming months.

gccrs 项目旨在为 GCC 编译器构建一个 Rust 前端，该项目在 2026 年上半年将重心放在了编译 Linux 内核上。通过针对内核 crate（软件包）测试编译器，开发团队在为其他 Rust 程序生成正确代码方面取得了重大进展。正如项目周报和月报中所述，这一工作发现并解决了诸如属性处理（2 月份报告中描述）、名称解析和资源管理（5 月份报告中详细说明）等领域的问题。目前，该编译器仅能处理简单的独立程序，但这种情况在未来几个月内可能会迅速改变。

The drive to compile the Rust components of the Linux kernel stems from the new toolchain requirements brought by Rust’s introduction into the kernel. Currently, developers must use the LLVM-based rustc compiler (although rustc does have experimental, in-progress support for using GCC as a backend via rust_codegen_gcc). While LLVM is supported by the kernel, a GCC-based alternative is necessary to support architectures not targeted by LLVM and to integrate with GCC’s existing plugin ecosystem. As the kernel’s Rust integration matures, toolchain flexibility and the availability of a GCC-based compiler have become priorities for Linux distributions.

推动编译 Linux 内核中 Rust 组件的动力，源于 Rust 引入内核后带来的新工具链需求。目前，开发人员必须使用基于 LLVM 的 rustc 编译器（尽管 rustc 通过 rust_codegen_gcc 对使用 GCC 作为后端提供了实验性的、正在进行中的支持）。虽然内核支持 LLVM，但为了支持 LLVM 未覆盖的架构，并与 GCC 现有的插件生态系统集成，基于 GCC 的替代方案是必不可少的。随着内核对 Rust 的集成日益成熟，工具链的灵活性以及基于 GCC 的编译器的可用性已成为 Linux 发行版关注的重点。

Reorganizing milestones

里程碑重组

Compiler frontend projects often track their progress against the release cycle of their target backend. In its March 2026 report, the gccrs team announced a change in project management, opting to organize its work into three capability-based milestones rather than targeting specific GCC versions. The first milestone is an “embedded Rust compiler” capable of compiling no_std programs that depend only on the core crate. The second is a “Rust for Linux compiler” that supports the alloc crate alongside the specific crates used by the kernel. The final milestone is a “general purpose compiler” aimed at handling broader Rust applications beyond the kernel environment.

编译器前端项目通常会根据其目标后端的发布周期来跟踪进度。在 2026 年 3 月的报告中，gccrs 团队宣布了项目管理的变更，决定将工作组织为三个基于能力的里程碑，而不是针对特定的 GCC 版本。第一个里程碑是“嵌入式 Rust 编译器”，能够编译仅依赖 core crate 的 no_std 程序。第二个是“Linux Rust 编译器”，除了支持内核使用的特定 crate 外，还支持 alloc crate。最后一个里程碑是“通用编译器”，旨在处理内核环境之外更广泛的 Rust 应用程序。

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

第一个里程碑尚未完全实现，但已接近完成。向“Linux Rust 编译器”里程碑迈进的工作正在进行中。3 月份，团队增加了对 compiler_builtins 的支持，这是内核构建所需的关键底层 crate，并专注于解决内核 ffi crate 中的问题。为了支持这项工作，Zhi Heng 于 2026 年 5 月加入该项目，进行开源安全实习。他的工作致力于修复 gccrs 在编译内核 crate 时遇到的错误，并建立持续集成测试以防止回归。

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

然而，仅仅通过测试确保编译器能够处理 Rust 代码而不崩溃只是任务的一部分。生成的代码还必须是正确的。Rust 析构函数语义的实现是生成正确代码的关键，因为地道的 Rust 代码比传统的 C 代码更频繁地使用它们，因此这也是另一个重点关注领域。

The Drop infrastructure

Drop 基础设施

Rust manages resources using a scope-based model known as resource acquisition is initialization (RAII). When a value goes out of scope, the compiler automatically inserts a call to its destructor, which is defined by the Drop trait. In Rust, tracking when variables must be cleaned up is complex because a variable’s initialization state can change depending on the control flow within a function. If a variable is conditionally moved or only partially initialized, the compiler cannot simply drop it at the end of the enclosing scope.

Rust 使用一种称为“资源获取即初始化”（RAII）的基于作用域的模型来管理资源。当一个值超出作用域时，编译器会自动插入对其析构函数的调用，该析构函数由 Drop trait 定义。在 Rust 中，跟踪变量何时必须被清理非常复杂，因为变量的初始化状态可能会根据函数内的控制流而改变。如果变量被条件性移动或仅部分初始化，编译器不能简单地在封闭作用域结束时将其丢弃（drop）。

To solve this, the frontend must analyze the control-flow graph and generate dynamic “drop flags”—boolean variables tracked at run time—to record whether a value needs to be destroyed before passing this representation to the GCC backend. That analysis was missing from the initial implementation of Drop in gccrs, causing some Drop::drop() calls to be omitted or incorrect. In the context of the Linux kernel, missing Drop calls lead to severe run-time failures, such as memory leaks or unreleased system resources.

为了解决这个问题，前端必须分析控制流图并生成动态的“drop 标志”（在运行时跟踪的布尔变量），以记录在将此表示传递给 GCC 后端之前，某个值是否需要被销毁。gccrs 最初的 Drop 实现中缺少这种分析，导致一些 Drop::drop() 调用被遗漏或不正确。在 Linux 内核的背景下，遗漏 Drop 调用会导致严重的运行时故障，例如内存泄漏或未释放的系统资源。

A primary example is lock management. When kernel code acquires a lock, the Rust for Linux API returns a MutexGuard. The Drop implementation for this guard is responsible for releasing the lock. As the team noted in May, without proper Drop calls, the lock is never released. This results in miscompiled code where locks remain held after their guard goes out of scope, which can cause synchronization failures or deadlocks. Google Summer of Code (GSoC) participant Janet Chien joined the project in May to focus specifically on building the gccrs Drop infrastructure.

一个主要的例子是锁管理。当内核代码获取锁时，Rust for Linux API 会返回一个 MutexGuard。该 guard 的 Drop 实现负责释放锁。正如团队在 5 月份指出的那样，如果没有正确的 Drop 调用，锁将永远不会被释放。这会导致编译出的代码在 guard 超出作用域后仍然持有锁，从而可能导致同步失败或死锁。Google Summer of Code (GSoC) 参与者 Janet Chien 于 5 月加入该项目，专门负责构建 gccrs 的 Drop 基础设施。

Name-resolution work

名称解析工作

Testing the compiler against the standard library and kernel crates also exposed highlighted fundamental bugs in how gccrs handled name resolution, although the project was already aware of many of them, and had begun working on name-resolution in particular in 2023. Rust maintains three distinct namespaces: the value namespace for functions and static variables, the macro namespace, and the type namespace for structures, modules, and traits. When the compiler encounters a “path”—a sequence of identifiers like crate::foo::bar used to refer to an item—it must identify the correct namespace for each segment of the path. The development team discovered a flaw in its processing pipeline. Previously, when gccrs looked for the definition of an item, it resolved paths within the namespace of the target item type. For instance, when looking for a function, it resolved the path segments in the value namespace. This approach is incorrect because modules and publicly visible imports actually live…

针对标准库和内核 crate 测试编译器，也暴露并突显了 gccrs 在处理名称解析方面的根本性错误，尽管项目组此前已经意识到了其中许多问题，并已于 2023 年开始专门研究名称解析。Rust 维护着三个不同的命名空间：用于函数和静态变量的值命名空间、宏命名空间，以及用于结构体、模块和 trait 的类型命名空间。当编译器遇到“路径”（即用于引用项的一系列标识符，如 crate::foo::bar）时，它必须为路径的每个段识别正确的命名空间。开发团队在其处理流水线中发现了一个缺陷。此前，当 gccrs 查找某个项的定义时，它会在目标项类型的命名空间内解析路径。例如，在查找函数时，它会在值命名空间中解析路径段。这种方法是不正确的，因为模块和公开可见的导入实际上位于……