Rustový frontend gccrs udělal krok k překladu linuxového jádra přes GCC

Linuxové jádro umí od roku 2022 přijímat kód napsaný v Rustu, jeho překlad ale zajišťuje výhradně rustc, oficiální kompilátor založený na LLVM. Projekt gccrs od roku 2020 staví alternativu – rustový frontend přímo pro GCC. Podle shrnutí na LWN.net a vlastních měsíčních zpráv věnoval tým první polovinu roku 2026 právě tomu, aby jím šlo přeložit rustové části jádra, a cestou odhalil a opravil několik zásadních chyb ve zpracování jmen, destruktorů i metadat.

Proč vedle LLVM ještě GCC

Rust v jádře dnes běží výhradně přes rustc s LLVM backendem – experimentální podpora GCC jako backendu přes rust_codegen_gcc existuje, ale samotný frontend zůstává rustc. LLVM ale nepokrývá všechny architektury, které umí GCC, a nedává přístup do jeho pluginového ekosystému. S tím, jak rustová část jádra roste, roste i tlak distribucí na to, aby toolchain nebyl vázaný na jediný kompilátor.

Tři milníky místo verzí GCC

V březnu 2026 tým přeorganizoval plán práce: místo cílení na konkrétní vydání GCC zavedl tři milníky podle schopností. „Embedded Rust compiler“ má zvládnout programy bez standardní knihovny, závislé jen na balíčku core. „Rust-for-Linux compiler“ k tomu přidá balíček alloc a konkrétní balíčky, které používá jádro. „General purpose compiler“ má nakonec zvládnout rustový kód obecně, ne jen jádro.

První milník je podle květnové zprávy skoro hotový. Druhý, klíčový pro jádro, stoupl z 16 procent v únoru na 35 v květnu. Dílčí čísla to rozepisují podrobněji: podpora balíčku compiler_builtins a funkce build_error je hotová na sto procent, balíček ffi na 40, ale makra jádra, rozhraní uapi i hlavní soubory jádra byly v květnu pořád na nule.

Chybějící destruktory

Rust spravuje zdroje modelem RAII: když hodnota vypadne ze scope, kompilátor sám zavolá její destruktor podle traitu Drop. Sledovat, kdy se má proměnná uklidit, je složité, protože stav její inicializace se mění podle průběhu programu – kompilátor proto musí analyzovat řídicí tok a generovat takzvané drop flags, tedy proměnné za běhu, které říkají, jestli je hodnotu ještě potřeba zrušit. Tahle analýza v gccrs podle LWN chyběla úplně, takže se volání Drop::drop() někdy vynechávalo nebo bylo špatně.

V jádru to není kosmetická chyba. Rust-for-Linux vrací při zamčení zámku takzvaný MutexGuard, jehož implementace Drop zámek uvolní. Bez správného volání Drop by zámek zůstal držený i po tom, co strážce vypadl ze scope – to znamená zablokovaný kód nebo deadlock. Na infrastruktuře pro Drop od května pracuje účastnice Google Summer of Code Janet Chien.

Jmenný prostor, který si kompilátor pletl

Testování na standardní knihovně a jádru odhalilo i chybu ve zpracování jmen. Rust rozlišuje čtyři jmenné prostory – pro hodnoty (funkce, statické proměnné), makra, typy a pro životnosti a návěští. Když gccrs hledal definici položky, hledal ji rovnou ve prostoru cílového typu: u funkce tedy ve prostoru hodnot. Jenže moduly a veřejně viditelné importy leží ve prostoru typů, takže bez jejich vyřešení tam kompilátor nedokázal projít cestou k funkci vůbec.

Oprava znamenala přepsat vnitřní datové struktury a část visitor kódu v celém překladači. Do května se tím podařilo správně rozpustit hluboko zanořené importy v balíčku core a chování se přiblížilo rustc.

Atributy pro jádro a chybějící metadata

Podle únorové zprávy přepracoval hlavní vývojář Pierre-Emmanuel Patry i zpracování atributů typu #[cfg()], které řídí podmíněný překlad. Odstraňování položek podle cfg rozdělil do dvou průchodů – bez toho nešlo podporovat nestabilní funkce jádra, které při expanzi maker potřebují atributy nejdřív odstranit a teprve pak validovat. V březnu k tomu přibyl přepínač -frust-crate-attr, obdoba přepínače -Zcrate-attr v rustc, který umí vložit atribut (třeba #![no_core]) při volání kompilátoru bez zásahu do zdrojového kódu.

Propojování rustových balíčků jádra pak odhalilo další chybu: exportovaná metadata v souborech .rlib některým balíčkům chyběla u vnořených modulů, takže se nepodařilo dohledat závislosti. Testy na to nenarazily, protože počítaly s plošší strukturou modulů – objevilo se to až na reálném kódu jádra a vyvolalo přepracování celého zpracování metadat.

Kde to dnes stojí

Gccrs dnes umí přeložit samostatné programy bez závislosti na core (no_core) a zvládá zpracovat kód balíčku core i většinu jádra po syntaktické stránce. Skutečné spuštění jádra je ale pořád daleko – ukazují to nulová procenta u maker, uapi a hlavních souborů jádra ve vlastním přehledu projektu. Letos začali přispívat i dva účastníci Google Summer of Code (Enes Çevik na balíčku alloc, Janet Chien na destruktorech) a stážista Zhi Heng, který se věnuje testům na kódu jádra a průběžné integraci.

Slabinou dlouho bylo prosazování změn do hlavního stromu GCC – rozsáhlé záplaty jako přepis jmenných prostorů narážely na omezenou kapacitu recenzentů. Podle LWN se to zlepšilo poté, co dva vývojáři gccrs dostali status správců GCC a mohou si změny připravovat ve vlastní větvi a slučovat je hromadně. Patry a Arthur Cohen mají letos přednášku „Compiling the Linux kernel with gccrs“ na RustConf v Montrealu a na EuroRust v Barceloně.

Výčet opravených chyb by mohl budit dojem, že má jádro k překladu blízko – čísla z vlastního přehledu gccrs ale ukazují, že klíčové části pro jeho spuštění jsou pořád na nule. Chyby, na které tým narazil (špatný jmenný prostor, chybějící destruktory, děravá metadata), jsou přesně ten druh problémů, který se v malých testech neprojeví a vyleze až na reálném kódu.

Zdroje

• Progress toward compiling Linux with gccrs, LWN.net, 28. července 2026
• May 2026 Monthly report, gccrs (Rust-GCC)
• February 2026 Monthly report, gccrs (Rust-GCC)
• Rust-GCC/gccrs, GitHub