Kemajuan menuju kompilasi Linux dengan gccrs

• gccrs, frontend Rust untuk GCC, menguji crate kernel Linux pada paruh pertama 2026, memperbaiki masalah pemrosesan atribut, resolusi nama, dan manajemen sumber daya, dan kini berfokus pada implementasi semantik eksekusi kode kernel secara akurat
• Kompiler Rust berbasis GCC diperlukan untuk memanfaatkan arsitektur yang tidak didukung LLVM serta ekosistem plugin GCC yang ada, dan juga dapat memberi distribusi Linux pilihan toolchain
• Pembuatan kode yang benar membutuhkan analisis drop flag dinamis berdasarkan alur kontrol; jika ini terlewat, MutexGuard tidak akan melepas kunci sehingga dapat menyebabkan kegagalan sinkronisasi atau deadlock
• Saat mengompilasi crate kernel sungguhan, terungkap masalah besar yang memicu pengerjaan ulang skala besar: struktur resolusi nama yang salah menangani tiga namespace Rust, urutan pemrosesan #[cfg()], dan metadata crate yang melewatkan modul bertingkat
• Dukungan untuk program no_core serta core dan compiler_builtins telah maju, tetapi kompilasi kernel penuh masih membutuhkan dukungan alloc dan semantik eksekusi yang akurat, serta masih tersisa peninjauan dan koordinasi untuk integrasi upstream GCC

---

Mengapa kernel Linux dijadikan target pengujian

• gccrs adalah proyek untuk mengembangkan frontend Rust bagi GCC, dan pada paruh pertama 2026 proyek ini berfokus pada kompilasi kernel Linux
  • Dengan menguji crate kernel, proyek ini menemukan dan memperbaiki masalah pemrosesan atribut, resolusi nama, dan manajemen sumber daya
  • Saat ini proyek ini baru dapat menangani program mandiri yang sederhana, tetapi pengujian kode kernel juga membawa kemajuan bagi pembuatan kode yang benar untuk program Rust lainnya
  • Perkembangannya dicatat dalam laporan mingguan dan laporan bulanan proyek
• Saat ini kode Rust dalam kernel Linux harus menggunakan rustc berbasis LLVM
  • rust_codegen_gcc yang eksperimental, yang menggunakan GCC sebagai backend untuk rustc, juga sedang dikembangkan
  • Alternatif berbasis GCC diperlukan untuk mendukung arsitektur yang tidak ditargetkan LLVM dan untuk berintegrasi dengan ekosistem plugin GCC yang ada
  • Seiring matangnya integrasi Rust di kernel, distribusi Linux menjadikan fleksibilitas toolchain dan ketersediaan kompiler berbasis GCC sebagai prioritas

Milestone berdasarkan kapabilitas, bukan versi GCC

• Dalam laporan Maret 2026, tim gccrs mengubah kerangka kerja dari menargetkan versi GCC tertentu menjadi tiga milestone berbasis kapabilitas
  • Kompiler Rust embedded: mengompilasi program no_std yang hanya bergantung pada core
  • Kompiler Rust for Linux: mendukung core dan crate tertentu yang digunakan kernel
  • Kompiler serbaguna: menangani aplikasi Rust yang lebih luas di luar lingkungan kernel
• Milestone pertama belum selesai, tetapi hampir tercapai, dan pekerjaan untuk milestone Rust for Linux juga telah dimulai
• Pada Maret 2026, dukungan untuk crate tingkat rendah compiler_builtins yang dibutuhkan build kernel ditambahkan, dan fokus diarahkan pada penyelesaian masalah crate ffi milik kernel
• Zhi Heng bergabung pada Mei 2026 melalui magang Open Source Security
  • Ia memperbaiki bug yang muncul saat gccrs mengompilasi crate kernel
  • Ia membangun pengujian integrasi berkelanjutan untuk mencegah regresi
• Sekadar memproses kode Rust tanpa crash tidaklah cukup; kode yang dihasilkan juga harus berperilaku benar
  • Kode Rust idiomatis lebih banyak menggunakan semantik destructor dibanding C, sehingga implementasi Drop menjadi inti dari pembuatan kode yang benar

Infrastruktur Drop untuk pelepasan sumber daya yang akurat

• Rust mengelola sumber daya dengan model RAII, yaitu resource acquisition is initialization; saat sebuah nilai keluar dari scope, kompiler otomatis memanggil destructor yang didefinisikan dalam trait Drop
• Status inisialisasi variabel dapat berubah tergantung alur kontrol di dalam fungsi
  • Jika sebuah nilai dipindahkan secara kondisional atau hanya sebagian diinisialisasi, nilai itu tidak bisa selalu dihapus tanpa syarat di akhir scope
  • Frontend harus menganalisis control-flow graph, membuat drop flag dinamis, yaitu variabel boolean yang mencatat saat runtime apakah sebuah nilai perlu di-drop, lalu meneruskannya ke backend GCC
• Implementasi awal Drop di gccrs tidak memiliki analisis ini, sehingga sebagian pemanggilan Drop::drop() terlewat atau dibuat secara keliru
• Dalam kernel Linux, hilangnya pemanggilan Drop dapat berujung pada kegagalan runtime serius seperti kebocoran memori dan tidak dikembalikannya sumber daya sistem
  • Saat sebuah lock diperoleh, API Rust for Linux mengembalikan MutexGuard
  • Implementasi Drop pada guard ini bertanggung jawab melepas lock
  • Tanpa pemanggilan Drop yang benar, lock tetap tertahan meski guard keluar dari scope, sehingga dapat terjadi kegagalan sinkronisasi atau deadlock
• Peserta GSoC Janet Chien bergabung pada Mei 2026 dan berfokus membangun infrastruktur Drop di gccrs

Penulisan ulang resolusi nama agar sesuai dengan namespace Rust

• Pengujian standard library dan crate kernel mengungkap bug resolusi nama mendasar di gccrs
  • Proyek ini sudah mengetahui beberapa masalah tersebut dan sejak 2023 telah memperbaiki resolusi nama secara terpisah
• Rust membedakan tiga namespace
  • Namespace nilai berisi fungsi dan variabel statis
  • Namespace makro berisi makro
  • Namespace tipe berisi struct, modul, dan trait
• Untuk memproses path seperti crate::foo::bar, setiap segmen identifier harus ditentukan termasuk ke namespace mana
• gccrs yang lama menafsirkan seluruh path dalam satu namespace sesuai jenis item yang pada akhirnya ingin ditemukan
  • Saat mencari fungsi, semua segmen path ditafsirkan dalam namespace nilai
  • Namun modul dan import publik berada di namespace tipe, sehingga struktur modul harus lebih dulu diikuti melalui namespace tipe agar fungsi dapat dicapai
• Untuk memperbaikinya, struktur data internal harus ditulis ulang dan implementasi visitor di seluruh kode harus direfaktor
  • Pada Mei 2026, import yang sangat bertingkat dalam crate core sudah dapat diresolusikan dengan benar
  • Dengan memasukkan modul dan import ke namespace tipe, perilakunya menjadi lebih dekat dengan rustc

Perbaikan atribut kondisional dan opsi kompiler

• Proses kompilasi crate kernel juga mengungkap masalah pada pemrosesan atribut kompiler dan metadata crate di gccrs
• Rust menggunakan atribut seperti #[cfg()] untuk melakukan kompilasi kondisional
• Pierre-Emmanuel Patry mengerjakan ulang pipeline pemrosesan atribut pada Februari 2026
  • Pass kompiler yang menghapus item yang dikecualikan oleh atribut cfg dipisahkan menjadi dua tahap
  • Beberapa fitur tidak stabil di kernel bergantung pada ekspansi makro atau atribut kondisional
  • Atribut seperti ini harus dihapus sebelum pass validasi atribut utama agar proses validasi tidak memunculkan error kompilasi
• Pada Maret 2026, opsi -frust-crate-attr ditambahkan sebagai padanan -Zcrate-attr milik rustc
  • Sistem build dapat menyuntikkan atribut saat pemanggilan kompiler tanpa mengubah file sumber asli
  • Ini berguna untuk meneruskan #![no_core] yang diperlukan saat mengompilasi kode tanpa library core standar
  • Pengembang yang melakukan fuzzing kompiler untuk menemukan bug kasus tepi juga menggunakan fitur ini

Metadata yang hilang terungkap dari kode kernel nyata

• Crate Rust umumnya mengekspor metadata yang disertakan dalam file .rlib untuk menyampaikan API publik ke crate lain
• Saat menautkan crate Rust milik kernel, ditemukan bahwa sebagian modul dan export hilang dari metadata yang dihasilkan
  • gccrs melewatkan export dari modul bertingkat saat membuat metadata
  • Akibatnya, dependensi eksternal tidak dapat diresolusikan
• Pengujian metadata yang ada menggunakan struktur modul datar sehingga tidak menemukan masalah ini; bug baru terungkap setelah kode nyata dikompilasi
• Pengerjaan ulang besar-besaran atas sistem pemrosesan metadata dimulai agar pohon dependensi kernel dapat ditautkan dengan toolchain GNU

Cakupan dukungan saat ini dan batasan upstream GCC

• Saat ini gccrs berhasil menangani program no_core mandiri
• Pemrosesan crate core dan implementasi compiler_builtins juga telah maju cukup jauh, tetapi pekerjaan untuk mengompilasi sepenuhnya abstraksi Rust kernel yang kompleks masih berlangsung
  • Kode kernel dapat diparse
  • Fokus saat ini adalah mengimplementasikan semantik runtime secara akurat
• Selain tantangan teknis, ada juga batasan organisasi dalam toolchain GNU yang harus dilewati
  • Skala pekerjaan untuk mengintegrasikan frontend bahasa baru yang berubah cepat secara penuh ke GCC sangat besar
  • Patch set besar kadang melampaui kapasitas peninjauan upstream GCC yang terbatas
  • Situasinya membaik seiring stabilnya struktur frontend
• Baru-baru ini dua pengembang gccrs dipromosikan menjadi maintainer GCC
  • Mereka kini dapat menyiapkan pembaruan di tree sendiri lalu menggabungkannya sekaligus

Dukungan alloc dan presentasi mendatang

• Peserta GSoC Enes Çevik bergabung pada Mei 2026 dan sedang mengimplementasikan dukungan untuk crate alloc
• alloc menangani tipe alokasi memori dinamis seperti Box, Rc, dan Vec
  • Pengembangan kernel menghindari banyak abstraksi standard library, tetapi sebagian abstraksi kernel Rust inti bergantung pada tipe alokasi
  • Karena itu, dukungan alloc menjadi prasyarat penting bagi milestone Rust for Linux
• Patry dan Arthur Cohen berencana memberikan presentasi “Compiling the Linux kernel with gccrs” pada paruh kedua 2026 di RustConf di Montreal dan EuroRust di Barcelona
• Dengan mengimplementasikan fitur yang dibutuhkan kode kernel satu demi satu, proyek ini membangun fondasi untuk mengompilasi kode Rust dalam ekosistem kernel Linux dengan GCC