Progrès vers la compilation de Linux avec gccrs

• gccrs, le frontal Rust pour GCC, a testé des crates du noyau Linux au premier semestre 2026, corrigé des problèmes de traitement des attributs, de résolution des noms et de gestion des ressources, et se concentre désormais sur l’implémentation de la sémantique d’exécution exacte du code du noyau
• Un compilateur Rust basé sur GCC est nécessaire pour exploiter les architectures non prises en charge par LLVM et l’écosystème existant des plugins GCC ; il peut aussi offrir aux distributions Linux davantage de choix de chaînes d’outils
• Une génération de code correcte exige une analyse dynamique des drop flags selon le flux de contrôle ; si elle manque, un MutexGuard peut ne pas libérer le verrou, entraînant des échecs de synchronisation ou des interblocages
• La compilation de véritables crates du noyau a révélé une architecture de résolution des noms qui gérait mal les trois espaces de noms de Rust, des problèmes d’ordre de traitement de #[cfg()] et des lacunes dans les métadonnées de crate omettant les modules imbriqués, ce qui a déclenché une refonte importante
• La prise en charge des programmes no_core ainsi que de core et compiler_builtins a progressé, mais la compilation complète du noyau nécessite encore la prise en charge de alloc et une sémantique d’exécution exacte ; il reste aussi du travail de revue et de coordination pour l’intégration en amont dans GCC

---

Pourquoi utiliser le noyau Linux comme cible de test

• gccrs est un projet qui développe un frontal Rust pour GCC ; au premier semestre 2026, il s’est concentré sur la compilation du noyau Linux
  • Les tests sur les crates du noyau ont permis de découvrir et de corriger des problèmes de traitement des attributs, de résolution des noms et de gestion des ressources
  • Il ne peut actuellement traiter que de simples programmes autonomes, mais les tests sur le code du noyau font aussi progresser la génération correcte de code pour d’autres programmes Rust
  • L’avancement est documenté dans les rapports hebdomadaires et les rapports mensuels du projet
• Le code Rust actuel du noyau Linux doit utiliser rustc, basé sur LLVM
  • Un rust_codegen_gcc expérimental, qui utilise GCC comme back-end dans rustc, est également en développement
  • Une alternative basée sur GCC est nécessaire pour prendre en charge les architectures que LLVM ne cible pas et pour s’intégrer à l’écosystème existant des plugins GCC
  • À mesure que l’intégration de Rust dans le noyau mûrit, les distributions Linux font de la flexibilité des chaînes d’outils et de la disponibilité d’un compilateur basé sur GCC une priorité

Des jalons définis par capacités plutôt que par version de GCC

• Dans son rapport de mars 2026, l’équipe gccrs a remplacé les objectifs liés à une version précise de GCC par trois jalons fondés sur les capacités
  • Compilateur Rust embarqué : compiler des programmes no_std ne dépendant que de core
  • Compilateur Rust for Linux : prendre en charge core et certaines crates utilisées par le noyau
  • Compilateur généraliste : traiter un éventail plus large d’applications Rust au-delà de l’environnement du noyau
• Le premier jalon n’est pas encore achevé, mais il est presque atteint, et le travail sur le jalon Rust for Linux a également commencé
• En mars 2026, l’équipe a ajouté la prise en charge de compiler_builtins, une crate de bas niveau nécessaire à la construction du noyau, et s’est concentrée sur la résolution des problèmes liés à la crate ffi du noyau
• Zhi Heng a rejoint le projet en mai 2026 dans le cadre d’un stage chez Open Source Security
  • Il corrige les bugs qui surviennent lorsque gccrs compile des crates du noyau
  • Il met en place des tests d’intégration continue pour éviter les régressions
• Il ne suffit pas de traiter du code Rust sans planter : le code généré doit aussi se comporter correctement
  • Le Rust idiomatique utilise davantage la sémantique des destructeurs que le C ; les implémentations de Drop sont donc essentielles à une génération de code correcte

Infrastructure Drop pour libérer correctement les ressources

• Rust gère les ressources selon le modèle RAII, où l’acquisition de ressource correspond à l’initialisation ; lorsqu’une valeur sort de portée, le compilateur appelle automatiquement le destructeur défini par le trait Drop
• L’état d’initialisation d’une variable peut dépendre du flux de contrôle à l’intérieur d’une fonction
  • Si une valeur est déplacée conditionnellement ou seulement partiellement initialisée, elle ne peut pas être détruite inconditionnellement à la fin de la portée
  • Le frontal doit analyser le graphe de flux de contrôle, créer des drop flags dynamiques — des variables booléennes qui enregistrent à l’exécution si une valeur doit être détruite — puis les transmettre au back-end GCC
• La première implémentation de Drop dans gccrs ne comportait pas cette analyse, ce qui entraînait l’omission ou la génération incorrecte de certains appels à Drop::drop()
• Dans le noyau Linux, l’absence d’appels à Drop peut provoquer de graves défaillances à l’exécution, comme des fuites de mémoire et la non-libération de ressources système
  • Lorsqu’un verrou est acquis, l’API Rust for Linux renvoie un MutexGuard
  • L’implémentation de Drop de ce guard est chargée de libérer le verrou
  • Sans appel correct à Drop, le verrou reste détenu lorsque le guard sort de portée, ce qui peut provoquer des échecs de synchronisation ou des interblocages
• Janet Chien, participante au GSoC, a rejoint le projet en mai 2026 pour se concentrer sur la construction de l’infrastructure Drop de gccrs

Réécriture de la résolution des noms selon les espaces de noms de Rust

• Les tests sur la bibliothèque standard et les crates du noyau ont mis en évidence des bugs fondamentaux de résolution des noms dans gccrs
  • Le projet connaissait déjà plusieurs problèmes et travaillait séparément à l’amélioration de la résolution des noms depuis 2023
• Rust distingue trois espaces de noms
  • L’espace de noms des valeurs contient les fonctions et les variables statiques
  • L’espace de noms des macros contient les macros
  • L’espace de noms des types contient les structures, modules et traits
• Pour traiter un chemin comme crate::foo::bar, il faut déterminer à quel espace de noms appartient chaque segment d’identifiant
• L’ancien gccrs résolvait tout le chemin dans un seul espace de noms, selon le type de l’élément recherché au final
  • Lorsqu’il cherchait une fonction, il résolvait tous les segments du chemin dans l’espace de noms des valeurs
  • Mais comme les modules et les imports publics se trouvent dans l’espace de noms des types, il faut d’abord suivre la structure des modules dans cet espace pour atteindre la fonction
• Corriger cela a nécessité de réécrire les structures de données internes et de refactorer les implémentations de visiteurs dans l’ensemble du code
  • En mai 2026, gccrs pouvait résoudre correctement les imports profondément imbriqués de la crate core
  • En insérant les modules et les imports dans l’espace de noms des types, son comportement s’est rapproché de celui de rustc

Amélioration des attributs conditionnels et des options du compilateur

• La compilation des crates du noyau a aussi révélé des problèmes dans le traitement des attributs du compilateur et dans les métadonnées de crate de gccrs
• Rust utilise des attributs comme #[cfg()] pour la compilation conditionnelle
• Pierre-Emmanuel Patry a retravaillé le pipeline de traitement des attributs en février 2026
  • Il a séparé en deux étapes la passe du compilateur qui retire les éléments exclus par les attributs cfg
  • Certaines fonctionnalités instables du noyau dépendent de l’expansion de macros ou d’attributs conditionnels
  • Ces attributs doivent être retirés avant la passe principale de validation des attributs pour éviter des erreurs de compilation pendant la validation
• En mars 2026, l’option -frust-crate-attr, équivalente à -Zcrate-attr de rustc, a été ajoutée
  • Elle permet aux systèmes de build d’injecter des attributs lors de l’appel au compilateur sans modifier les fichiers source d’origine
  • Elle est utile pour passer #![no_core], nécessaire à la compilation de code sans la bibliothèque standard core
  • Les développeurs qui fuzzent le compilateur pour trouver des bugs dans les cas limites utilisent aussi cette fonctionnalité

Métadonnées manquantes révélées par le vrai code du noyau

• Les crates Rust exportent généralement des métadonnées incluses dans des fichiers .rlib afin de transmettre leur API publique aux autres crates
• Lors de l’édition de liens des crates Rust du noyau, il est apparu que certains modules et exports manquaient dans les métadonnées générées
  • gccrs omettait les exports de modules imbriqués lors de la génération des métadonnées
  • Par conséquent, les dépendances externes ne pouvaient pas être résolues
• Les tests de métadonnées existants utilisaient une structure de modules plate et n’avaient pas détecté ce problème ; le bug n’est apparu qu’après la compilation de code réel
• Une refonte importante du système de traitement des métadonnées a commencé afin de permettre l’édition de liens de l’arbre de dépendances du noyau avec la chaîne d’outils GNU

Portée actuelle de la prise en charge et contraintes d’intégration en amont dans GCC

• Actuellement, gccrs peut traiter avec succès des programmes no_core autonomes
• Le traitement de la crate core et l’implémentation de compiler_builtins ont également beaucoup progressé, mais la compilation complète des abstractions Rust complexes du noyau est toujours en cours
  • Le code du noyau peut être analysé syntaxiquement
  • L’objectif actuel est d’implémenter correctement la sémantique d’exécution
• Outre les défis techniques, il faut aussi surmonter les contraintes organisationnelles de la chaîne d’outils GNU
  • L’intégration dans GCC d’un nouveau frontal de langage évoluant rapidement représente un travail considérable
  • De grands ensembles de correctifs ont parfois dépassé la capacité limitée de revue en amont de GCC
  • La situation s’améliore à mesure que l’architecture du frontal se stabilise
• Deux développeurs de gccrs ont récemment été promus mainteneurs GCC
  • Ils peuvent préparer les mises à jour dans leur propre arbre, puis les intégrer en bloc

Prise en charge de alloc et prochaines présentations

• Enes Çevik, participant au GSoC, a rejoint le projet en mai 2026 pour implémenter la prise en charge de la crate alloc
• alloc fournit les types d’allocation dynamique de mémoire comme Box, Rc et Vec
  • Le développement du noyau évite plusieurs abstractions de la bibliothèque standard, mais certaines abstractions Rust essentielles du noyau dépendent de types alloués
  • La prise en charge de alloc est donc une condition nécessaire au jalon Rust for Linux
• Patry et Arthur Cohen prévoient de présenter “Compiling the Linux kernel with gccrs” à la RustConf à Montréal et à EuroRust à Barcelone au second semestre 2026
• En implémentant une à une les fonctionnalités requises par le code du noyau, le projet construit les bases nécessaires à la compilation du code Rust de l’écosystème du noyau Linux avec GCC