GCC 的 Rust 前端 gccrs 編譯 Linux kernel 程式碼進度過半
LWN.net · 2026-09-22
背景
Linux kernel 目前已經允許在特定子系統中以 Rust 撰寫程式碼，但正式支援的編譯器只有以 LLVM 為後端的 rustc，這代表只要 rustc 尚未移植到某個處理器架構，那個架構上的內核就無法開啟 Rust 相關功能。gccrs 是 GNU 編譯器套件（GCC）自行開發的 Rust 前端，目標是讓內核裡的 Rust 程式碼改由 GCC 編譯，藉此涵蓋 LLVM 尚未支援、但 GCC 已長年支援的處理器架構，同時與 GCC 既有的外掛與除錯工具鏈整合。對於跑在冷門架構、或不想被迫綁定單一編譯器供應商的內核維護者而言，這個缺口一直是無法迴避的痛點。
今年稍早的報告已經提到，gccrs 團隊自 2026 年上半年起把主力放在編譯內核所需的 Rust crate 上，而不是先追求一般用途的完整語言支援。Pierre-Emmanuel Patry 與 Arthur Cohen 在 RustConf 2026 上共同發表了 gccrs 現況，隔週 Patry 又在 Kangrejos（內核 Rust 開發者聚會）單獨對內核開發者重講一次，Cohen 當次並未出席。兩場演講傳達的訊息一致：進度紮實，但編譯器距離可用仍需要時間。
規格細節
根據 gccrs 專案 2026 年 8 月的月報，代號 LC 0.1 的里程碑——也就是讓 gccrs 能編譯內核實際用到的 Rust 程式碼——完成度從 7 月的 45% 推進到 55%。同一時間，內核依賴的 core 函式庫（core 1.49）型別檢查修正進度，也從 12% 跳升到 60%。這兩項數字都直接來自專案當月發布的技術報告，反映的是編譯器內部功能覆蓋率，而不是內核已經可以完整編譯。
報告同時列出尚未支援、但內核程式碼會用到的語言特性，包括 ExtractIf 疊代器、泛型參數推斷、is_multiple_of 方法、任意 self 型別（Receiver trait）、CFI 型別編碼覆寫，以及 CoercePointee trait；其中 CFI 型別編碼部分需要和 GCC 維護者協調，目前仍在處理中。8 月份團隊合併了 79 個 pull request，測試案例通過數來到 11,549 筆，累計關閉 647 個 bug，目前共有 11 名開發者參與。
| 指標 | 2026 年 7 月 | 2026 年 8 月 |
|---|---|---|
| LC 0.1 里程碑完成度 | 45% | 55% |
| core 1.49 型別檢查修正進度 | 12% | 60% |
| 測試案例通過數 | 11,325 | 11,549 |
| 累計關閉 bug 數 | 634 | 647 |
影響範圍
第一個受影響的族群，是想在非 LLVM 架構上跑內核 Rust 程式碼的維護者：只要 gccrs 還沒補齊 core 與 alloc crate 的支援，這些架構就只能繼續等待，或乾脆放棄在該平台啟用 Rust 子系統。第二個族群，是維運建置系統的團隊，他們如果打算把 gccrs 接進既有的 GCC 工具鏈與 CI 流程，現在就該檢查自己用到的 crate 是否落在報告列出的未支援清單裡，例如 ExtractIf 或 CoercePointee。
值得留意的是，兩位主要開發者 Patry 與 Cohen 今年從原雇主 Embecosm 離職，工作改由 Open Source Security, Inc 承接以維持專案延續性，這類人事變動對規畫 gccrs 導入時程的團隊也是需要納入考量的風險因素。短期內，gccrs 仍改變不了任何人現有的編譯流程，但如果 8 月這種成長速度維持下去，選用哪家編譯器編譯內核 Rust 程式碼，會愈來愈只是工具鏈選項，而非架構限制。
原始來源：LWN.net - Compiling the kernel with gccrs、gccrs 專案 2026 年 8 月月報