Discussion :

[Bill Fassinou]

GCC se dote d'un nouveau frontend pour le langage de programmation Rust
une version préliminaire de ce compilateur appelé "gccrs" devrait être incluse dans GCC 13

Le projet "gccrs", qui vise à fournir un frontend pour le langage Rust à GCC (GNU Compiler Collection), est en bonne voie pour être intégré à GCC 13. À la conférence des développeurs FOSDEM au début du mois, l'ingénieur Arthur Cohen a fait une présentation sur gccrs exposant l'état actuel des travaux. Bien que le frontend gccrs ait été fusionné pour la prochaine version GCC 13, il n'est pas encore dans un état qui sera vraiment utilisable par la plupart des développeurs Rust en tant qu'alternative au compilateur officiel LLVM de Rust. Il ne devrait pas l'être avant l'année prochaine, au moins avec GCC 14 au moins.

Le projet gccrs est une implémentation alternative complète du langage Rust au-dessus de GCC avec l'objectif de devenir complètement en amont de la chaîne d'outils GNU. L'origine de ce projet est un effort de la communauté il y a plusieurs années, alors que Rust était encore à la version 0.9 ; le langage créé par Mozilla était sujet à tant de changements qu'il devenait difficile pour un effort de la communauté de rattraper le retard. Maintenant que le langage est stable, c'est le moment pour créer des compilateurs alternatifs. Le développement est dirigé par des "Rustaceans" enthousiastes et a connu une accélération au cours des trois dernières années.

« Commencé en 2014 (et relancé en 2019), l'effort est en cours depuis 2020 et nous avons fait beaucoup d'efforts et beaucoup de progrès. Nous avons mis en amont la première version de gccrs au sein de GCC. Ainsi, la prochaine fois que vous installerez GCC 13, vous aurez gccrs à l'intérieur. Vous pouvez l'utiliser et vous pouvez commencer à pirater dessus, vous pouvez s'il vous plaît signaler les problèmes quand il se plante inévitablement et meurt horriblement. Une grande chose que nous faisons est un travail pour faire fonctionner la suite de tests rustc », a déclaré Arthur Cohen lors de sa présentation à la conférence FOSDEM au début du mois.

« Nous voulons que gccrs soit un vrai compilateur Rust et non un projet jouet ou quelque chose qui compile un langage qui ressemble à Rust, mais qui n'est pas Rust ; nous essayons vraiment de faire fonctionner cette suite de tests », a-t-il ajouté. Lors de la présentation, Cohen a également déclaré que, bien que le frontend Rust de GCC 13 ait pris un bon départ, il y a encore beaucoup de travail à faire. Le code de vérification des emprunts est notablement absent pour le moment, le support des modules intégrés et des intrinsèques est toujours en cours, et l'étape importante de la compilation du code Rust for Linux n'a pas encore été franchie.

La capacité à exécuter avec succès la suite de tests du compilateur rustc reste également un objectif à atteindre. Selon Cohen, l'interface GCC de Rust vise également l'ancienne version 1.49 de Rust libcore. La FAQ du projet gccrs note que l'ensemble des technologies de compilation de LLVM - que Rust utilise - "manque de certains backends que GCC supporte, donc une implémentation de gccrs peut combler les lacunes pour une utilisation dans le développement embarqué". Cependant, veuillez noter que le compilateur Rust-GCC (gccrs) est encore à un stade très précoce et qu'il n'est pas encore utilisable pour compiler de vrais programmes Rust.

L'équipe de GCC a voté en juillet dernier pour approuver l'intégration de gccrs à la suite de compilateurs. L'importance de ce projet réside dans sa signification pour le noyau Linux. En effet, le noyau Linux est généralement construit avec GCC, mais les plans visant à permettre l'utilisation du langage Rust aux côtés de C pour le code du noyau, pour des raisons de sécurité de la mémoire, progressent régulièrement. Le projet "Rust for Linux" a été officiellement fusionné dans l'arbre Git principal de Linux 6.1 en octobre dernier, faisant de Rust le deuxième langage dédié au développement de Linux, après 31 ans de développement exclusivement en C.

Pour rappel, le projet "Rust for Linux" vise à introduire un nouveau langage de programmation système dans le noyau Linux. Selon les experts, le langage Rust a une propriété clé qui le rend très intéressant à considérer comme le deuxième langage du noyau Linux : il garantit qu'aucun comportement indéfini n'a lieu (tant que le code non sécurisé est sain). Cela inclut l'absence d'erreurs de type use after-free, double frees, data races, etc. Les débats y relatifs tournent au tour de la possibilité d’une mise au rebut du C au profit du langage Rust. Mais Linus Torvalds, le créateur de Linux, a déclaré que ce n'est pas l'objectif déclaré du projet Rust for Linux.

Dans un communiqué en juillet dernier, David Edelsohn, membre fondateur du comité directeur de GCC, a déclaré : « nous sommes impatients d'inclure une version préliminaire et bêta de GCC Rust dans GCC 13 ». GCC a un calendrier de publication annuel. La version 12.1 a été publiée en mai 2022. Ainsi, on peut s'attendre à ce que GCC 13 soit disponible vers le mois de mai de cette année. Notons que GCC possède déjà un backend pour Rust, un projet appelé "rustc_codegen_gcc" fondé par Antoni Boucher. Il est toujours décrit comme un travail en cours, mais a été fusionné dans le dépôt principal de Rust en septembre 2021.

Cela signifie que le compilateur rustc peut être utilisé avec le backend GCC, le backend étant le générateur de code qui supporte plus d'architectures CPU que LLVM, le compilateur backend habituel de Rust, bien qu'il y ait des limitations telles que la nécessité d'une version patchée de GCC. Le projet gccrs consiste à développer une chaîne d'outils GCC complète.

Sources : présentation d'Arthur Cohen à la conférence FOSDEM de février 2023, gccrs

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi

Rust for Linux est officiellement fusionné, le support initial de Rust for Linux fournit l'infrastructure de base et une intégration élémentaire

L'inclusion de Rust for Linux à la version 6.1 du noyau est désormais en cours comme souhaité par Linus Torvalds et va rendre possible le développement de pilotes dans un autre langage que le C

Après 31 ans, un deuxième langage sera admis pour le développement du noyau Linux : c'est le Rust, considéré par plusieurs comme candidat idéal pour la mise au rebut du langage C

GCC 13 prend désormais en charge Modula-2, le descendant de Pascal ; il supporte également le langage Rust

[Jade Emy]

Progrès vers un compilateur Rust basé sur GCC, le projet gccrs est un effort ambitieux pour implémenter un compilateur Rust au sein de la GNU Compiler Collection (GCC).

Le projet gccrs est un effort ambitieux commencé en 2014 pour implémenter un compilateur Rust au sein de la collection de compilateurs GNU (GCC). Même si la tâche est loin d'être achevée, des progrès ont été réalisés depuis la précédente couverture de LWN, selon les rapports du projet. Entre-temps, une autre approche hybride et plus mature de la génération de code GCC Rust est disponible dans rustc_codegen_gcc.

En 2022, l'objectif de gccrs était d'être inclus dans la version 13 de GCC, mais cette attente n'a pas été satisfaite. L'équipe vise actuellement l'inclusion dans GCC 14 (probablement à la mi-2024), à en juger par son rapport mensuel de novembre 2023.

Le 13 octobre, Arthur Cohen a donné une conférence intitulée "The road to compiling the standard library with gccrs" à EuroRust 2023. Dans sa présentation, Cohen a donné quelques informations générales sur gccrs mais s'est surtout concentré sur le travail effectué récemment pour compiler la bibliothèque standard de Rust, et pourquoi gccrs ne peut pas encore le faire.

Gccrs cible une version spécifique de Rust, 1.49, sortie fin 2020, plutôt que d'essayer de suivre le développement rapide du langage Rust. Cette version a été choisie parce qu'elle est la plus récente avant le support des const generics, qui ont été introduits dans la version 1.50. Cependant, M. Cohen a regretté dans son exposé que le projet n'ait pas été en mesure d'ignorer les const generics après tout, car ils sont utilisés dans la bibliothèque standard, même dans la version 1.49. Ils ont été "stabilisés" pour une disponibilité générale dans la version 1.50, mais il y a une utilisation interne de la bibliothèque standard dans les versions antérieures également. Cependant, les const generics ont été entièrement implémentés depuis, et ce problème n'est plus un obstacle.

Beaucoup d'attention est portée à ce que gccrs ne devienne pas un "superset" de Rust, comme l'a dit Cohen. Le projet veut s'assurer qu'il ne crée pas un langage spécial "GNU Rust", mais essaie plutôt de reproduire le résultat de rustc - les bugs, les bizarreries et tout le reste. Les suites de tests de Rust et de GCC sont utilisées à cette fin.

La bibliothèque standard de Rust se compose d'un certain nombre de "crates", qui sont les noms des logiciels dans le jargon de Rust. Cohen a expliqué que gccrs travaille sur la compilation des deux crates les plus importants : core et alloc. Le crate core est la base de la bibliothèque standard, mettant en œuvre des fonctionnalités telles que les types primitifs et les macros ; alloc traite de l'allocation de la mémoire du tas et de divers types de conteneurs.

Actuellement, gccrs n'est pas en mesure de compiler ces crates en raison de diverses lacunes, telles qu'un comportement incorrect dans la résolution des noms de macros et un support incomplet des macros de décorateurs. L'absence d'un vérificateur d'emprunts (discuté plus bas), bien que ne bloquant pas la compilation, signifie que le compilateur ne peut pas vérifier correctement la sécurité du code. Un obstacle supplémentaire est constitué par l'absence d'éléments intrinsèques du compilateur dans GCC. Rustc utilise certains intrinsèques fournis par LLVM qui ne sont pas supportés par GCC, ce qui signifie que l'équipe gccrs doit passer du temps à les implémenter dans GCC.

Un autre exposé a été donné par Pierre-Emmanuel Patry au chaudron des outils GNU en septembre 2023. Il s'est principalement concentré sur les progrès vers l'inclusion dans GCC 14 ainsi que sur les macros, qui semblent être une question interdépendante parce que l'approche pour implémenter les macros procédurales nécessite des changements dans le système de construction de GCC. Les macros procédurales sont des macros de type fonction qui émettent des flux de jetons plutôt que du texte de code source brut comme les macros C ou C++. Elles sont implémentées dans une caisse intégrée appelée proc_macro. Ces macros sont notoirement difficiles à mettre en œuvre, mais elles sont également puissantes ; elles constituent le cœur de fonctionnalités telles que les décorateurs #[attribute] et #[derive()], et peuvent être utilisées pour créer des langages spécifiques à un domaine, évalués à la compilation.

Lors de la conférence GNU Cauldron, Patry a également mentionné que gccrs avait plus de 800 commits qui attendaient d'être transférés à GCC.

Tirer parti de l'écosystème GCC

L'exposé de Cohen à EuroRust a mis en évidence le fait que l'une des principales raisons pour lesquelles gccrs est développé est de pouvoir tirer parti des modules de sécurité de GCC. Il existe une large gamme de plugins GCC qui peuvent aider au débogage, à l'analyse statique ou au durcissement ; ces plugins travaillent sur la représentation intermédiaire de GCC. Gccrs a l'intention de soutenir les flux de travail où les développeurs peuvent réutiliser ces plugins avec du code Rust. À titre d'exemple, Cohen a mentionné que "les programmeurs C oublient de fermer leurs descripteurs de fichiers depuis 40 ans, [donc] il y a beaucoup de plugins pour rattraper cela". Gccrs vise à permettre aux programmeurs Rust d'utiliser les plugins GCC et les analyseurs statiques existants pour détecter les bogues dans le code non sécurisé.

M. Cohen a dressé une liste de choses pour lesquelles Gccrs est déjà utile. Selon lui, la communauté Sega Dreamcast homebrew utilise gccrs pour créer de nouveaux jeux pour la console de jeu Dreamcast, et les plugins GCC peuvent déjà être utilisés pour effectuer une analyse statique sur du code Rust non sécurisé. L'intérêt de la communauté Dreamcast provient du fait que le backend LLVM de rustc ne supporte pas l'architecture Hitachi SH-4 de la console, alors que GCC le supporte ; même dans son état incomplet, gccrs est utile pour ce cas d'utilisation embarqué.

En outre, il a mentionné que l'effort de gccrs a révélé certaines caractéristiques non spécifiées du langage, telles que Deref et la résolution des noms de macro ; en réponse, le projet a été en mesure de contribuer à des ajouts à la spécification de Rust. Actuellement, Rust n'a pas de spécification formelle, mais des travaux sont en cours pour en créer une, comme le propose la RFC 3355. "Les membres de gccrs veulent participer à cet effort, a déclaré M. Cohen.

Une autre raison d'être de gccrs est Rust for Linux, l'initiative visant à ajouter le support de Rust au noyau Linux. Cohen a déclaré que le noyau Linux est une motivation clé pour le projet parce qu'il y a beaucoup de personnes qui préfèrent que le noyau soit compilé uniquement par la chaîne d'outils GNU.

Choses en cours de développement

Il manque encore à Gccrs de nombreuses fonctionnalités de base. Cohen a énuméré plusieurs fonctionnalités importantes, telles que async/await, les intrinsèques LLVM qui sont absentes dans GCC, et la macro format_args !() utilisée par les macros de sortie telles que println !(). Le vérificateur d'emprunts, qui est un sous-système du compilateur qui applique les règles de référence du langage, est une fonctionnalité clé de Rust que gccrs devra fournir. Cohen a brièvement mentionné que la solution probable est un projet séparé de vérificateur d'emprunts appelé Polonius, et a dit que Gccrs l'intégrera probablement quelques mois plus tard. Le contributeur Jakub Dupak a fait des progrès à ce sujet au cours des derniers mois.

Polonius est une bibliothèque qui implémente un vérificateur d'emprunts qui est sémantiquement équivalent au vérificateur (pas tout à fait impeccablement implémenté) dans rustc aujourd'hui, en abordant le calcul des durées de vie des références avec un algorithme radicalement différent. Polonius vise à résoudre un jour les lacunes et les cas particuliers du vérificateur d'emprunts actuel de rustc. Une fois qu'il aura atteint sa maturité, il est probable que Rustc lui-même l'adoptera à l'avenir.

Selon le rapport mensuel de gccrs pour novembre 2023, le travail a commencé sur la macro format_args !(). Cette macro d'aide est responsable de la construction des paramètres pour d'autres macros de formatage de chaînes. Elle implique les traits Display et Debug, et est nécessaire pour préparer les arguments qui sont ensuite transmis à d'autres macros telles que format !() et println !(). Sans format_args !(), un programme Rust ne peut pas créer de sortie formatée ; cette fonctionnalité est donc nécessaire pour que gccrs puisse compiler un programme "Hello, World".

rustc_codegen_gcc

Il existe un autre projet Rust basé sur GCC, appelé rustc_codegen_gcc, qui est plus mature et dont la portée est plus limitée que celle de gccrs. Il ne s'agit pas d'une implémentation complète d'un compilateur Rust à partir de la base ; à la place, il utilise la bibliothèque libgccjit pour s'accrocher à une API du backend LLVM utilisé par rustc. Cette approche permet d'effectuer une grande partie de la compilation avec rustc et de passer à GCC à un stade ultérieur. Malgré le terme "JIT" (juste à temps) dans le nom de la bibliothèque, rustc_codegen_gcc est destiné à la compilation en avance de phase. Son objectif principal est de permettre la génération de code Rust sur des plateformes non supportées par LLVM.

Depuis octobre 2023, rustc_codegen_gcc peut désormais compiler Rust pour Linux sans aucun correctif supplémentaire. Au cours de l'année écoulée, le projet semble avoir bien progressé sur de nombreux fronts ; par exemple, il a ajouté la prise en charge des opérations SIMD (instruction unique, données multiples) et l'optimisation du temps de liaison, deux éléments qui avaient été précédemment identifiés comme des causes d'échec des tests. Cohen a fait référence à rustc_codegen_gcc à plusieurs reprises dans son exposé à EuroRust, encourageant les participants à l'utiliser au lieu de gccrs pour l'instant. En fait, il est déjà intégré dans le référentiel du langage Rust.

Rust pour Linux

Actuellement, le projet Rust pour Linux fournit de la documentation sur l'utilisation de rustc ou de rustc_codegen_gcc pour construire du code Rust pour le noyau. Le noyau contient également de la documentation sur les versions minimales supportées de divers outils de construction, y compris les compilateurs. Pour rustc, la version est considérée comme une correspondance exacte, plutôt qu'un minimum. La version de rustc actuellement supportée est la 1.73.0 (publiée en octobre 2023), bien plus récente que la 1.49 visée par gccrs. La prise en charge de Rust pour Linux est également un objectif déclaré de gccrs, mais en raison de cet écart important, il semble que l'on en soit encore loin.

Gccrs a bien progressé au cours de l'année écoulée depuis la dernière fois que nous l'avons examiné : le dépôt a bien plus de 3 000 commits depuis le 1er janvier 2023. Cependant, il n'est pas encore dans un état utilisable pour presque tous les objectifs pratiques, car en tant qu'implémentation complète à partir de la base, gccrs est beaucoup plus ambitieux dans sa portée que rustc_codegen_gcc. Ce dernier est déjà intégré au dépôt Rust en amont et est utilisé dans le monde réel avec Rust pour Linux. Nous ne sommes pas encore dans un monde avec de multiples implémentations d'un compilateur pour le langage Rust, mais nous nous en rapprochons.

Sources : Ronja Koistinen, LWN

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

GCC se dote d'un nouveau frontend pour le langage de programmation Rust, une version préliminaire de ce compilateur appelé "gccrs" devrait être incluse dans GCC 13

Rust dans le noyau Linux: un projet prometteur, mais pas sans complications. La communauté dresse un bilan lors de l'édition 2023 du Kernel Maintainers Summit

La première version officielle de GCC 13 est sur le point d'être publiée, mais n'inclura pas gccrs, le frontend pour le langage Rust. Le compilateur gccrs ne serait pas prêt pour du "vrai" code Rust