Fortschritte auf dem Weg, Linux mit gccrs zu kompilieren

• gccrs, das Rust-Frontend für GCC, hat im ersten Halbjahr 2026 Linux-Kernel-Crates als Testfall genutzt, dabei Probleme bei Attributverarbeitung, Namensauflösung und Ressourcenverwaltung behoben und konzentriert sich nun auf die Umsetzung der korrekten Ausführungssemantik von Kernel-Code
• Ein GCC-basierter Rust-Compiler wird benötigt, um Architekturen zu unterstützen, die LLVM nicht abdeckt, und das bestehende GCC-Plugin-Ökosystem zu nutzen; zudem könnte er Linux-Distributionen mehr Auswahl bei der Toolchain bieten
• Für korrekte Codegenerierung ist eine dynamische Drop-Flag-Analyse entlang des Kontrollflusses nötig; fehlt sie, kann etwa MutexGuard Sperren nicht freigeben, was zu Synchronisationsfehlern oder Deadlocks führen kann
• Beim Kompilieren realer Kernel-Crates zeigten sich eine fehlerhafte Namensauflösungsstruktur für die drei Rust-Namespaces, Probleme mit der Verarbeitungsreihenfolge von #[cfg()] sowie Crate-Metadaten, in denen verschachtelte Module fehlten, was eine größere Überarbeitung auslöste
• Bei no_core-Programmen sowie der Unterstützung für core und compiler_builtins gibt es Fortschritte, doch für eine vollständige Kernel-Kompilierung sind alloc-Unterstützung und korrekte Ausführungssemantik weiterhin nötig; außerdem stehen noch Review und Abstimmung für die GCC-Upstream-Integration aus

---

Warum der Linux-Kernel als Testziel gewählt wurde

• gccrs ist ein Projekt zur Entwicklung eines Rust-Frontends für GCC und hat sich im ersten Halbjahr 2026 auf das Kompilieren des Linux-Kernels konzentriert
  • Beim Testen mit Kernel-Crates wurden Probleme bei Attributverarbeitung, Namensauflösung und Ressourcenverwaltung entdeckt und behoben
  • Derzeit können zwar nur einfache eigenständige Programme verarbeitet werden, doch die Tests mit Kernel-Code bringen auch Fortschritte bei der korrekten Codegenerierung für andere Rust-Programme
  • Der Fortschritt ist in den Wochenberichten und Monatsberichten des Projekts dokumentiert
• Der Rust-Code im Linux-Kernel erfordert derzeit das LLVM-basierte rustc
  • Das experimentelle rust_codegen_gcc, das GCC als Backend für rustc verwendet, wird ebenfalls entwickelt
  • Eine GCC-basierte Alternative ist nötig, um Architekturen zu unterstützen, die LLVM nicht als Ziel hat, und um sich in das bestehende GCC-Plugin-Ökosystem zu integrieren
  • Mit der Reifung der Rust-Integration im Kernel priorisieren Linux-Distributionen Flexibilität bei der Toolchain und die Verfügbarkeit eines GCC-basierten Compilers

Meilensteine nach Fähigkeiten statt nach GCC-Versionen

• Das gccrs-Team hat in seinem Bericht vom März 2026 seine Arbeitsstruktur von einem Ziel auf eine bestimmte GCC-Version auf drei fähigkeitsbasierte Meilensteine umgestellt
  • Embedded-Rust-Compiler: kompiliert no_std-Programme, die nur von core abhängen
  • Rust-for-Linux-Compiler: unterstützt core und bestimmte vom Kernel verwendete Crates
  • Allzweck-Compiler: verarbeitet ein breiteres Spektrum von Rust-Anwendungen über die Kernel-Umgebung hinaus
• Der erste Meilenstein ist noch nicht vollständig erreicht, liegt aber nahe; auch die Arbeit am Rust-for-Linux-Meilenstein hat bereits begonnen
• Im März 2026 wurde Unterstützung für das Low-Level-Crate compiler_builtins hinzugefügt, das für Kernel-Builds nötig ist, und man konzentrierte sich auf die Behebung von Problemen mit dem ffi-Crate des Kernels
• Zhi Heng stieß im Mai 2026 über ein Praktikum bei Open Source Security dazu
  • Er behebt Bugs, die auftreten, wenn gccrs Kernel-Crates kompiliert
  • Außerdem baut er Continuous-Integration-Tests auf, um Regressionen zu verhindern
• Es reicht nicht aus, Rust-Code nur ohne Absturz zu verarbeiten; auch der erzeugte Code muss korrekt funktionieren
  • Idiomatischer Rust-Code nutzt Destruktor-Semantik stärker als C, daher ist eine korrekte Codegenerierung für Drop entscheidend

Drop-Infrastruktur für korrekte Ressourcenfreigabe

• Rust verwaltet Ressourcen mit dem RAII-Modell, bei dem Ressourcenbindung zugleich Initialisierung ist, und der Compiler ruft automatisch den im Drop-Trait definierten Destruktor auf, wenn ein Wert den Gültigkeitsbereich verlässt
• Der Initialisierungszustand von Variablen kann je nach Kontrollfluss innerhalb einer Funktion unterschiedlich sein
  • Wenn ein Wert nur bedingt verschoben wird oder nur teilweise initialisiert ist, kann er am Ende des Gültigkeitsbereichs nicht immer bedingungslos freigegeben werden
  • Das Frontend muss den Kontrollflussgraphen analysieren, dynamische Drop-Flags erzeugen — boolesche Variablen, die zur Laufzeit festhalten, ob ein Wert freigegeben werden muss — und diese an das GCC-Backend übergeben
• In der anfänglichen Drop-Implementierung von gccrs fehlte diese Analyse, wodurch einige Drop::drop()-Aufrufe ausblieben oder falsch erzeugt wurden
• Im Linux-Kernel können fehlende Drop-Aufrufe zu schweren Laufzeitfehlern wie Speicherlecks oder nicht freigegebenen Systemressourcen führen
  • Beim Erwerb einer Sperre liefert die Rust-for-Linux-API einen MutexGuard zurück
  • Die Drop-Implementierung dieses Guards ist für das Entsperren zuständig
  • Ohne korrekte Drop-Aufrufe bleibt die Sperre auch nach Verlassen des Gültigkeitsbereichs bestehen, was zu Synchronisationsfehlern oder Deadlocks führen kann
• Die GSoC-Teilnehmerin Janet Chien stieß im Mai 2026 dazu und konzentriert sich auf den Aufbau der Drop-Infrastruktur in gccrs

Neuschreiben der Namensauflösung passend zu Rust-Namespaces

• Tests mit der Standardbibliothek und Kernel-Crates haben grundlegende Bugs in der Namensauflösung von gccrs offengelegt
  • Das Projekt kannte bereits mehrere dieser Probleme und arbeitet seit 2023 separat an Verbesserungen der Namensauflösung
• Rust unterscheidet drei Namespaces
  • Zum Value-Namespace gehören Funktionen und statische Variablen
  • Zum Macro-Namespace gehören Makros
  • Zum Type-Namespace gehören Structs, Module und Traits
• Um Pfade wie crate::foo::bar zu verarbeiten, muss bestimmt werden, zu welchem Namespace jeder Abschnitt eines Bezeichnerpfads gehört
• Bisher löste gccrs den gesamten Pfad in einem einzigen Namespace auf, je nach Art des Zielobjekts, das am Ende gefunden werden sollte
  • Beim Suchen einer Funktion wurden alle Pfadsegmente im Value-Namespace aufgelöst
  • Module und öffentliche Imports liegen jedoch im Type-Namespace; deshalb muss zuerst die Modulstruktur im Type-Namespace verfolgt werden, bevor die Funktion erreicht werden kann
• Um das zu korrigieren, mussten interne Datenstrukturen neu geschrieben und Visitor-Implementierungen im gesamten Code refaktoriert werden
  • Im Mai 2026 wurde erreicht, dass tief verschachtelte Imports im core-Crate korrekt aufgelöst werden können
  • Durch das Einfügen von Modulen und Imports in den Type-Namespace nähert sich das Verhalten stärker an rustc an

Verbesserungen bei bedingten Attributen und Compiler-Optionen

• Beim Kompilieren von Kernel-Crates traten auch Probleme bei der Compiler-Attributverarbeitung und den Crate-Metadaten in gccrs zutage
• Rust nutzt Attribute wie #[cfg()] für bedingte Kompilierung
• Pierre-Emmanuel Patry überarbeitete im Februar 2026 die Pipeline zur Attributverarbeitung
  • Er teilte den Compiler-Pass zum Entfernen von durch cfg-Attribute ausgeschlossenen Elementen in zwei Stufen auf
  • Einige instabile Features des Kernels hängen von Makroexpansion oder bedingten Attributen ab
  • Solche Attribute müssen vor dem Haupt-Pass zur Attributvalidierung entfernt werden, damit dort keine Compilerfehler entstehen
• Im März 2026 wurde die Option -frust-crate-attr hinzugefügt, das Gegenstück zu rustc--Zcrate-attr
  • Damit kann ein Build-System beim Compileraufruf Attribute einschleusen, ohne die Quelldateien selbst zu verändern
  • Das ist nützlich, um #![no_core] zu übergeben, das zum Kompilieren ohne die Standard-core-Bibliothek nötig ist
  • Auch Entwickler, die den Compiler fuzzing-basiert auf Randfälle testen, nutzen diese Funktion

In realem Kernel-Code sichtbar gewordene fehlende Metadaten

• Rust-Crates exportieren üblicherweise Metadaten, die in .rlib-Dateien enthalten sind, um anderen Crates ihre öffentliche API bereitzustellen
• Beim Linken der Rust-Crates des Kernels zeigte sich, dass einige Module und Exporte in den erzeugten Metadaten fehlten
  • gccrs ließ beim Erzeugen der Metadaten Exporte verschachtelter Module aus
  • Dadurch konnten externe Abhängigkeiten nicht aufgelöst werden
• Bestehende Metadaten-Tests mit flacher Modulstruktur hatten dieses Problem nicht entdeckt; erst beim Kompilieren realen Codes wurde der Bug sichtbar
• Daher wurde mit einer umfassenden Überarbeitung des Metadaten-Verarbeitungssystems begonnen, damit sich der Kernel-Abhängigkeitsbaum mit der GNU-Toolchain linken lässt

Aktueller Unterstützungsumfang und Grenzen beim GCC-Upstreaming

• Derzeit kann gccrs eigenständige no_core-Programme erfolgreich verarbeiten
• Auch bei der Verarbeitung des core-Crates und der Implementierung von compiler_builtins gibt es erhebliche Fortschritte, doch das vollständige Kompilieren der komplexen Rust-Abstraktionen des Kernels ist noch in Arbeit
  • Kernel-Code kann bereits geparst werden
  • Der aktuelle Fokus liegt auf der korrekten Umsetzung der Laufzeitsemantik
• Neben den technischen Herausforderungen müssen auch organisatorische Hürden der GNU-Toolchain überwunden werden
  • Der Umfang der Integration eines neuen, sich schnell entwickelnden Sprach-Frontends in GCC ist groß
  • Große Patch-Serien überstiegen teils die begrenzten Review-Kapazitäten im GCC-Upstream
  • Mit der Stabilisierung der Frontend-Struktur verbessert sich die Lage jedoch
• Kürzlich wurden zwei gccrs-Entwickler zu GCC-Maintainern befördert
  • Dadurch können sie Updates zunächst im eigenen Tree vorbereiten und anschließend gesammelt einpflegen

alloc-Unterstützung und kommende Vorträge

• Der GSoC-Teilnehmer Enes Çevik stieß im Mai 2026 dazu und implementiert Unterstützung für das alloc-Crate
• alloc ist zuständig für dynamisch allokierende Typen wie Box, Rc und Vec
  • Die Kernel-Entwicklung vermeidet zwar viele Abstraktionen der Standardbibliothek, doch einige zentrale Rust-Kernel-Abstraktionen hängen von allokierenden Typen ab
  • Daher ist alloc-Unterstützung eine Voraussetzung für den Rust-for-Linux-Meilenstein
• Patry und Arthur Cohen planen für später im Jahr 2026 Vorträge mit dem Titel „Compiling the Linux kernel with gccrs“ auf der RustConf in Montreal und der EuroRust in Barcelona
• Durch die schrittweise Implementierung der vom Kernel-Code geforderten Funktionen schaffen sie die Grundlage dafür, Rust-Code im Linux-Kernel-Ökosystem mit GCC zu kompilieren