Tiến triển hướng tới việc biên dịch Linux bằng gccrs

• gccrs, frontend Rust cho GCC, đã thử nghiệm crate của nhân Linux trong nửa đầu năm 2026, sửa các vấn đề về xử lý thuộc tính, phân giải tên và quản lý tài nguyên, và hiện tập trung vào việc hiện thực chính xác ngữ nghĩa thực thi của mã nhân
• Để tận dụng các kiến trúc mà LLVM không hỗ trợ và hệ sinh thái plugin GCC hiện có, cần một trình biên dịch Rust dựa trên GCC; điều này cũng có thể mang lại quyền lựa chọn toolchain cho các bản phân phối Linux
• Để sinh mã chính xác cần có phân tích dynamic drop flag theo luồng điều khiển; nếu thiếu, MutexGuard có thể không nhả khóa, dẫn tới lỗi đồng bộ hóa hoặc deadlock
• Khi biên dịch các crate nhân thực tế, đã lộ ra cấu trúc phân giải tên xử lý sai ba namespace của Rust, thứ tự xử lý #[cfg()], và vấn đề metadata crate bỏ sót các module lồng nhau, khiến dự án phải tái cấu trúc quy mô lớn
• Hỗ trợ cho chương trình no_core cùng core và compiler_builtins đã có tiến triển, nhưng để biên dịch đầy đủ nhân vẫn cần thêm hỗ trợ alloc và ngữ nghĩa thực thi chính xác, đồng thời vẫn còn việc rà soát và phối hợp để tích hợp upstream vào GCC

---

Vì sao chọn nhân Linux làm đối tượng thử nghiệm

• gccrs là dự án phát triển frontend Rust cho GCC, và trong nửa đầu năm 2026 đã tập trung vào việc biên dịch nhân Linux
  • Trong quá trình thử nghiệm các crate của nhân, dự án đã phát hiện và sửa các vấn đề về xử lý thuộc tính, phân giải tên và quản lý tài nguyên
  • Hiện tại mới chỉ xử lý được các chương trình độc lập đơn giản, nhưng việc thử nghiệm với mã nhân cũng giúp cải thiện khả năng sinh mã đúng cho các chương trình Rust khác
  • Tiến độ được ghi lại trong báo cáo hằng tuần và báo cáo hằng tháng của dự án
• Hiện nay mã Rust trong nhân Linux phải dùng rustc dựa trên LLVM
  • Một dự án thử nghiệm là rust_codegen_gcc, dùng GCC làm backend cho rustc, cũng đang được phát triển
  • Một lựa chọn thay thế dựa trên GCC là cần thiết để hỗ trợ các kiến trúc mà LLVM không nhắm tới và để tích hợp với hệ sinh thái plugin GCC sẵn có
  • Khi tích hợp Rust vào nhân ngày càng trưởng thành, các bản phân phối Linux đang xem tính linh hoạt của toolchain và khả năng có trình biên dịch dựa trên GCC là ưu tiên quan trọng

Các cột mốc chia theo năng lực thay vì phiên bản GCC

• Trong báo cáo tháng 3/2026, nhóm gccrs đã chuyển từ việc nhắm tới một phiên bản GCC cụ thể sang hệ thống làm việc theo ba cột mốc dựa trên năng lực
  • Trình biên dịch Rust cho embedded: biên dịch các chương trình no_std chỉ phụ thuộc vào core
  • Trình biên dịch Rust for Linux: hỗ trợ core và một số crate cụ thể mà nhân sử dụng
  • Trình biên dịch đa dụng: xử lý các ứng dụng Rust rộng hơn ngoài môi trường nhân
• Cột mốc đầu tiên vẫn chưa hoàn tất nhưng đã rất gần, và công việc cho cột mốc Rust for Linux cũng đã bắt đầu
• Trong tháng 3/2026, dự án đã bổ sung hỗ trợ cho crate mức thấp compiler_builtins cần cho việc build nhân, đồng thời tập trung giải quyết các vấn đề với crate ffi của nhân
• Zhi Heng tham gia vào tháng 5/2026 thông qua kỳ thực tập của Open Source Security
  • Anh đã sửa các lỗi phát sinh khi gccrs biên dịch các crate của nhân
  • Đồng thời xây dựng kiểm thử tích hợp liên tục để ngăn lỗi hồi quy
• Chỉ xử lý mã Rust mà không bị crash là chưa đủ; mã được sinh ra cũng phải hoạt động chính xác
  • Mã Rust theo phong cách idiomatic dùng ngữ nghĩa destructor nhiều hơn C, nên việc sinh mã đúng cho Drop là then chốt

Hạ tầng Drop để giải phóng tài nguyên chính xác

• Rust quản lý tài nguyên theo mô hình RAII, trong đó việc giành quyền sở hữu tài nguyên đồng nghĩa với khởi tạo; khi giá trị ra khỏi phạm vi, trình biên dịch sẽ tự động gọi destructor được định nghĩa trong Drop trait
• Trạng thái khởi tạo của biến có thể thay đổi theo luồng điều khiển bên trong hàm
  • Nếu một giá trị bị move có điều kiện hoặc chỉ được khởi tạo một phần, không thể luôn luôn hủy nó ở cuối phạm vi
  • Frontend phải phân tích control-flow graph để tạo ra dynamic drop flag, một biến boolean ghi lại ở runtime liệu giá trị có cần bị hủy hay không, rồi chuyển thông tin đó cho backend GCC
• Cách hiện thực Drop ban đầu của gccrs không có phân tích này, khiến một số lời gọi Drop::drop() bị bỏ sót hoặc được sinh ra sai
• Trong nhân Linux, việc bỏ sót lời gọi Drop có thể dẫn tới lỗi runtime nghiêm trọng như rò rỉ bộ nhớ và không trả lại tài nguyên hệ thống
  • Khi lấy một khóa, API Rust for Linux sẽ trả về MutexGuard
  • Phần hiện thực Drop của guard này chịu trách nhiệm mở khóa
  • Nếu không có lời gọi Drop đúng, khóa vẫn bị giữ ngay cả khi guard ra khỏi phạm vi, có thể gây lỗi đồng bộ hóa hoặc deadlock
• Người tham gia GSoC Janet Chien gia nhập vào tháng 5/2026 và tập trung xây dựng hạ tầng Drop cho gccrs

Viết lại phân giải tên để phù hợp với namespace của Rust

• Việc thử nghiệm với thư viện chuẩn và các crate của nhân đã làm lộ ra lỗi phân giải tên mang tính nền tảng trong gccrs
  • Dự án đã biết trước nhiều vấn đề và từ năm 2023 đã cải tiến phân giải tên như một phần riêng biệt
• Rust phân biệt ba namespace
  • Namespace giá trị chứa các hàm và biến tĩnh
  • Namespace macro chứa macro
  • Namespace kiểu chứa struct, module và trait
• Để xử lý một đường dẫn như crate::foo::bar, cần xác định mỗi đoạn định danh thuộc namespace nào
• Trước đây gccrs phân giải toàn bộ đường dẫn trong một namespace duy nhất theo loại mục tiêu cần tìm cuối cùng
  • Khi tìm hàm, mọi đoạn của đường dẫn đều được phân giải trong namespace giá trị
  • Nhưng module và public import lại nằm trong namespace kiểu, nên phải lần theo cấu trúc module trong namespace kiểu trước rồi mới đến được hàm
• Để sửa điều này, nhóm phải viết lại các cấu trúc dữ liệu nội bộ và refactor phần triển khai visitor trên diện rộng
  • Tới tháng 5/2026, dự án đã có thể phân giải đúng các import lồng sâu trong crate core
  • Việc chèn module và import vào namespace kiểu giúp hành vi gần hơn với rustc

Cải thiện thuộc tính có điều kiện và tùy chọn trình biên dịch

• Trong quá trình biên dịch các crate của nhân, các vấn đề về xử lý thuộc tính của trình biên dịch và metadata crate trong gccrs cũng lộ ra
• Rust dùng các thuộc tính như #[cfg()] để biên dịch có điều kiện
• Pierre-Emmanuel Patry đã làm lại pipeline xử lý thuộc tính vào tháng 2/2026
  • Ông tách thành hai giai đoạn compiler pass loại bỏ các mục bị loại trừ bởi thuộc tính cfg
  • Một số tính năng unstable của nhân phụ thuộc vào macro expansion hoặc thuộc tính có điều kiện
  • Những thuộc tính như vậy phải được loại bỏ trước pass kiểm tra thuộc tính chính, nếu không quá trình kiểm tra sẽ gây lỗi biên dịch
• Vào tháng 3/2026, dự án đã thêm tùy chọn -frust-crate-attr tương đương với -Zcrate-attr của rustc
  • Hệ thống build có thể chèn thuộc tính ngay tại lệnh gọi trình biên dịch mà không cần sửa file mã nguồn gốc
  • Điều này hữu ích khi truyền #![no_core], thứ cần thiết để biên dịch mã không dùng thư viện core chuẩn
  • Các nhà phát triển fuzzing trình biên dịch để tìm bug ở các trường hợp biên cũng dùng tính năng này

Thiếu sót metadata lộ ra từ mã nhân thực tế

• Các crate Rust thường xuất metadata được chứa trong file .rlib để truyền API công khai sang các crate khác
• Khi liên kết các crate Rust của nhân, người ta phát hiện một số module và export bị thiếu trong metadata được sinh ra
  • gccrs đã bỏ sót export của các module lồng nhau trong quá trình tạo metadata
  • Kết quả là không thể phân giải các phụ thuộc bên ngoài
• Các bài kiểm thử metadata trước đây dùng cấu trúc module phẳng nên không phát hiện ra vấn đề này; chỉ sau khi biên dịch mã thực thì bug mới lộ ra
• Dự án đã bắt đầu tái cấu trúc quy mô lớn hệ thống xử lý metadata để có thể liên kết cây phụ thuộc của nhân bằng toolchain GNU

Phạm vi hỗ trợ hiện tại và các ràng buộc upstream của GCC

• Hiện tại gccrs có thể xử lý thành công các chương trình no_core độc lập
• Việc xử lý crate core và hiện thực compiler_builtins cũng đã tiến triển đáng kể, nhưng công việc để biên dịch hoàn toàn các abstraction Rust phức tạp của nhân vẫn đang tiếp diễn
  • Dự án có thể phân tích cú pháp mã nhân
  • Trọng tâm hiện nay là hiện thực chính xác ngữ nghĩa runtime
• Bên cạnh các thách thức kỹ thuật, dự án còn phải vượt qua các ràng buộc mang tính tổ chức của toolchain GNU
  • Quy mô công việc để tích hợp một frontend ngôn ngữ mới thay đổi nhanh vào GCC là rất lớn
  • Các bộ patch lớn đôi khi vượt quá năng lực review upstream có hạn của GCC
  • Tình hình đang cải thiện khi cấu trúc frontend dần ổn định
• Gần đây, 2 nhà phát triển gccrs đã được thăng cấp thành GCC maintainer
  • Nhờ đó họ có thể chuẩn bị các bản cập nhật trong cây riêng rồi đưa vào cùng lúc

Hỗ trợ alloc và các bài trình bày sắp tới

• Người tham gia GSoC Enes Çevik đã gia nhập vào tháng 5/2026 để hiện thực hỗ trợ cho crate alloc
• alloc phụ trách các kiểu cấp phát bộ nhớ động như Box, Rc, Vec
  • Việc phát triển nhân tránh nhiều abstraction của thư viện chuẩn, nhưng một số abstraction Rust cốt lõi trong nhân vẫn phụ thuộc vào các kiểu cấp phát
  • Vì vậy, hỗ trợ alloc là điều kiện bắt buộc cho cột mốc Rust for Linux
• Patry và Arthur Cohen dự kiến sẽ trình bày “Compiling the Linux kernel with gccrs” tại RustConf ở Montreal và EuroRust ở Barcelona vào cuối năm 2026
• Bằng cách lần lượt hiện thực các tính năng mà mã nhân yêu cầu, dự án đang xây nền tảng để biên dịch mã Rust của hệ sinh thái nhân Linux bằng GCC