LWN:使用 gccrs 编译 Linux 的进展

2026年7月28日 

本文由 Arshal Aromal 撰写 

为 GCC (GNU Compiler Collection) 编译器创建 Rust 前端（frontend）的 gccrs 项目，在 2026 年上半年将工作重点放在了编译 Linux 内核上。通过针对内核 crate 进行编译器测试，开发团队在为其他 Rust 程序生成正确代码方面取得了重大进展。正如该项目的 周报 和 月报 中详细介绍的那样，这项工作已经发现并解决了诸如属性处理（在 2 月份报告 中描述）、名称解析（name resolution）以及资源管理（均在 5 月份报告中详细说明）等领域的问题。目前，该编译器只能处理简单的独立程序，但这种情况在未来几个月内可能会发生快速变化。 

编译 Linux 内核的 Rust 组件这一驱动力，源自 Rust 引入内核后带来的新工具链（toolchain）要求。目前，开发人员必须使用基于 LLVM 的 rustc 编译器（尽管 rustc 已经通过 rust_codegen_gcc 对使用 GCC 作为后端（backend）提供了实验性的、正在进行中的支持）。虽然内核支持 LLVM，但为了支持 LLVM 未支持的架构并与 GCC 现有的插件生态系统集成，基于 GCC 的替代方案是必不可少的. 随着内核 Rust 集成的成熟，工具链的灵活性和基于 GCC 的编译器的可用性已成为 Linux 发行版的首要任务。 

编译器前端项目通常根据其目标后端的发布周期来追踪其进展。在其 2026 年 3 月报告 中， gccrs 团队宣布了项目管理的变更，选择将其工作组织为三个基于功能的里程碑，而不是针对特定的 GCC 版本。 

第一个里程碑是“嵌入式 Rust 编译器（embedded Rust compiler）”，能够编译仅依赖于 core crate 的 no_std 程序。第二个是“Linux 版 Rust 编译器（Rust for Linux compiler）”，专注于支持内核使用的特定 crate。最终的里程碑是“通用编译器（general purpose compiler）”，旨在处理内核环境之外更广泛的 Rust 应用。 

第一个里程碑尚未完全实现，但已经接近完成。迈向“Linux 版 Rust 编译器”里程碑的进展正在进行中。为支持这项工作，Zhi Heng 于 2026 年 5 月加入该项目，担任 Open Source Security 实习生。他的工作致力于修复 gccrs 在编译内核 crate 时遇到的漏洞（bug），并建立持续集成（continuous-integration）测试以防止回归（regression）。 

然而，仅仅进行测试以确保编译器能够处理 Rust 代码而不会崩溃只是任务的一部分。生成的代码也必须是正确的。Rust 析构函数（destructor）语义的实现是生成正确代码的关键，因为符合习惯的（idiomatic）Rust 代码比传统的 C 代码更大量地使用它们，因此这也是另一个关注点。 

Rust 使用一种被称为 资源获取即初始化（RAII，Resource Acquisition Is Initialization）的基于作用域的模型来管理资源。当一个值超出作用域时，编译器会自动插入对其析构函数的调用，该析构函数由 Drop trait 定义。 

在 Rust 中，追踪变量何时必须被清理是复杂的，因为变量的初始化状态可能会根据函数内的控制流（control flow）而改变。如果一个变量被条件式地移动（moved）或仅被部分初始化，编译器就不能简单地在包含它的作用域结束时将其 drop。为了解决这个问题，前端必须分析控制流图（control-flow graph）并生成动态的“drop 标志（drop flags）”——在运行时追踪的布尔变量——以记录在将此表示形式传递给 GCC 后端之前是否需要销毁某个值。在最近关于编译器的这项工作之前， gccrs 完全缺乏 Drop 阐述（elaboration）。 

在 Linux 内核的上下文中，丢失 Drop 调用会导致严重的运行时失败，例如内存泄漏或未释放的系统资源。一个主要的例子是锁管理。当内核代码获取锁时，Linux 版 Rust API 会返回一个 MutexGuard 。该 guard 的 Drop 实现负责释放锁。 

正如团队在 5 月份指出的那样，如果没有适当的 Drop 调用，锁就永远不会被释放。这会导致代码编译错误：锁在其 guard 超出作用域后仍然保持持有状态，从而可能导致同步失败或死锁。Google Summer of Code (GSoC) 参与者 Janet Chien 于 5 月加入该项目，专门负责构建 gccrs 的 Drop 基础设施。 

针对标准库和内核 crate 测试编译器，还暴露了 gccrs 如何处理名称解析（name resolution）中的根本性 bug。 

Rust 维护了四个不同的命名空间（namespace）：用于函数和静态变量的值命名空间（value namespace）、宏命名空间（macro namespace）、类型命名空间（type namespace），以及用于生命周期（lifetime）和控制流标签的命名空间。当编译器遇到“路径（path）”——用于引用项的一系列标识符，如 crate::foo::bar ——时，它必须为路径的每个片段识别正确的命名空间。 

开发团队在其处理管线中发现了一个缺陷。以前，当 gccrs 寻找一个项的定义时，它会在目标项类型的命名空间内解析路径。例如，当寻找一个函数时，它会在值命名空间中解析路径片段。这种方法是不正确的，因为模块和公开可见的导入（import）实际上位于类型命名空间中；如果编译器不首先在类型命名空间中解析模块结构本身，就无法成功遍历路径来找到函数。 

修复这个问题需要重构内部数据结构，并对整个代码中使用的访问者（visitor）实现进行重构。到 5 月份，这些更改使得 core crate 中的深度嵌套导入能够正确解析。模块和导入现在被正确插入到类型命名空间中，这使 gccrs 与 rustc 的行为更加一致。 

转向编译内核 crate 凸显了 gccrs 在处理编译器属性（attribute）和 crate 元数据方面存在的进一步问题。 

Rust 依赖于诸如 #[cfg()] 之类的属性来实现条件编译。2026 年 2 月的报告描述了首席开发人员 Pierre-Emmanuel Patry 如何重构属性处理管线。他的 工作 将移除被 cfg 属性排除的项的编译器过程拆分为两个不同的处理阶段（pass）。这种分离对于支持内核中的不稳定特性是必要的；其中一些特性依赖于宏展开（macro expansion）或条件属性，这些属性必须在主属性验证阶段能够安全地评估它们之前被剥离，以免触发编译器错误。 

在 3 月份， gccrs 添加了一个相当于 rustc 的 -Zcrate-attr 的命令行选项，名为 -frust-crate-attr 。该选项允许构建系统在调用编译器时注入属性，而无需修改底层源文件。这对于传递 #![no_core] 属性特别有用，该属性是在不依赖标准 core 库的情况下编译代码所必需的。正在对编译器进行模糊测试（fuzzing）以定位边界情况 bug 的开发人员经常依赖这一特性。 

链接内核的 Rust crate 最终暴露出一个新的 bug。Rust crate 导出元数据（通常打包在 .rlib 文件中），以便向其他 crate 传达其公共 API。在尝试链接内核代码时，开发人员发现某些模块和导出在生成的元数据中完全缺失。由于编译器在生成元数据时省略了嵌套模块导出， gccrs 无法解析外部依赖项。 

项目现有的元数据测试用例没有捕获到这个问题，这些测试用例依赖于更扁平的模块结构。识别这个 bug 需要编译真实世界的代码。因此，团队开始对元数据处理系统进行重大重构，以确保 GNU 工具链能够成功链接内核的依赖树。 

那么， gccrs 今天能做什么？目前，该编译器可以成功处理独立的 no_core 程序，并且在处理 core crate 和实现编译器内建函数（compiler builtins）方面取得了重大进展。然而，完全编译内核复杂的 Rust 抽象仍然是一项正在进行中的工作。 gccrs 目前能够解析内核的代码，项目正专注于正确实现运行时语义。 

除了技术障碍之外， gccrs 还必须应对 GNU 工具链的组织挑战。历史上，该项目在将补丁合并到上游（upstream）GCC 树中时遇到了问题。将一个全新的、快速演进的语言前端集成到 GCC 中是一项巨大的任务，而补丁集的大小有时超出了上游 GCC 评审人员有限的带宽。更大的变化是最近将两名 gccrs 开发人员提升为 GCC 维护者（maintainers），这允许他们在自己的代码树中暂存更新，然后将其整体推送。 

编译内核所需的其余组件的工作仍在继续。同样在 5 月加入该项目的 GSoC 参与者 Enes Çevik 正在实现对 alloc crate 的支持。这个 crate 处理动态内存分配类型，如 Box、Rc 和 Vec。尽管内核开发避免了许多标准库抽象，但几个核心的内核 Rust 抽象依赖于分配类型。虽然早期版本的内核 Rust 集成依赖于标准 alloc=crate 的一个分支（fork），但内核最近已过渡到使用其自己的自定义 =alloc 模块。因此，编译标准的 alloc crate 不再是“Linux 版 Rust 编译器”里程碑的硬性前提条件，尽管它对于编译器更广泛的能力而言仍然是一个重要的步骤。 

更广泛的开发社区很快将有机会近距离了解这一进展. Patry 和 Arthur Cohen 计划在今年晚些时候于蒙特利尔举行的 RustConf 和巴塞罗那举行的 EuroRust 上发表题为“使用 gccrs 编译 Linux内核（Compiling the Linux kernel with gccrs）”的演讲。通过系统地解决内核代码的具体要求，该项目正在稳步为在 Linux 内核生态系统中使用 GCC 编译 Rust 代码打下基础。 

[ 注：文章中已添加了关于 alloc 和 compiler_builtins 库状态的几项更正。 ] 

• 读者讨论焦点：读者对文章中顺便提及的 codegen_gcc 项目产生了好奇，并对其当前的发展状态以及是否能够用于编译 Linux 内核提出了疑问。
• 核心疑问：有读者指出，印象中 codegen_gcc 的进展似乎比 gccrs 更快，甚至已经具备了编译内核的能力，因此希望了解该项目的最新实际进展与定位。