Gcc sur mesure avec MELT

1. Introduction

1.1 La complexité de Gcc

Le compilateur Gcc (Gnu Compiler Collection) est le compilateur de référence pour les systèmes Linux et les logiciels libres. Il peut compiler du code source en C, C++, Ada, Fortran, mais aussi Java, Objective C, et même Go... Sous Linux, beaucoup de logiciels essentiels sont compilés avec Gcc : le noyau Linux, les shells comme bash et les interpréteurs comme python ou perl, les bibliothèques comme Glibc, les environnements graphiques Gnome/Gtk ou KDE/Qt, les supports d'exécution des langages de haut niveau comme Java, Ruby ou Ocaml, etc. C'est pourquoi le mouvement GNU considère Gcc comme une brique essentielle du logiciel libre ; GNU/Linux ne pourrait pas s'en passer.

Le compilateur Gcc lit du code source (en C, C++, etc.), produit du code assembleur et pilote des programmes de binutils tels que l'éditeur de liens ld ou l'assembleur as. Les tâches d'analyse syntaxique (syntax parsing) et d'émission de code assembleur (ou parfois de code machine) genéré sont communes à tous les compilateurs, même les plus petits, comme Tiny CC. Mais l'essentiel du travail de Gcc consiste en de nombreuses optimisations, pour que le code généré soit plus performant tout en respectant la sémantique du code source. Sans optimisations, un compilateur ne peut pas profiter de la puissance des processeurs actuels, car ceux-ci sont extrêmement complexes et hétérogènes ; le langage C n'est plus en 2011 un langage assez proche du code machine, comme il l'était dans les années 1980. Le code machine x86 n'est plus semblable aux processeurs AMD/Phenom ou Intel/Core i5 de nos ordinateurs : ces processeurs traduisent à la volée, et différemment, le code machine x86 en micro-opérations. C'est pourquoi un exécutable optimisé pour une machine AMD pourrait être moins efficace sur un Intel et réciproquement. Chaque cœur d'un processeur est constitué de nombreuses unités (de décodage, de calcul entier ou flottant, de cache, de prédiction de branchements, etc.) qui travaillent simultanément : l'ordonnancement (scheduling) des instructions machines devient primordial (car elles peuvent être exécutées indépendamment, en parallèle, dans un même cœur). La bonne utilisation du cache est déterminante (car l'accès à une donnée dans les barrettes de RAM est 300 fois plus lent qu'à celles dans le cache du processeur). Gcc optimise en tenant compte de tous ces aspects.

Gcc est donc un très gros logiciel (5 millions de lignes de code source), développé par une communauté importante (plusieurs centaines de développeurs à temps plein, souvent salariés de grosses entreprises comme Google, AMD, Intel, IBM, Redhat, ...). La qualité de Gcc est due à la revue systématique par les pairs : chaque modification (ou patch), même petite, du compilateur doit être approuvée par un reviewer distinct de l'auteur qui la propose. Le compilateur Gcc est auto-amorcé (bootstrapped) : il se compile lui-même pendant son installation. L'aptitude à bien se compiler lui-même est un gage de qualité : si Gcc est capable de bien compiler son propre code (qui est complexe et dont le style est hétérogène), il sera probablement capable de bien compiler le votre !

Gcc est organisé en des frontaux (« front-ends ») qui transforment le code de chaque langage source en une représentation interne commune, une imposante couche médiane (« middle-end ») qui malaxe les représentations intermédiaires ; enfin, la couche arrière (« back-end ») génère le code assembleur (qui deviendra un fichier objet). Il y a de nombreuses passes (plus de 200 !) dans Gcc où les représentations internes sont malaxées comme dans un pétrin.

Il existe de nombreuses représentations internes dans Gcc (représentées par près de 2000 structures de données différentes). Les plus importantes y sont :

- Generic et Tree pour représenter la syntaxe du code source ;

- Gimple pour une représentation des instructions (à 3 adresses) ;

- basic_block pour les blocs élémentaires d'instructions Gimple ;

- edge pour les arêtes joignant des blocs.

Ces deux dernières servent (avec d'autres) à représenter le graphe de flot de contrôle qui définit l'ordre d'exécution du programme compilé.

1.2 Traiter spécifiquement du code source avec votre Gcc

Il est souvent utile de traiter du code source (et pas seulement pour le compiler en du code machine). Ces traitements pourraient se faire à l'aide du compilateur Gcc convenablement étendu : vos extensions de Gcc profiteraient alors de toute la puissance de travail du compilateur. Ces extensions spécifiques (à une entreprise, un logiciel, un projet, ...) pourraient :

- fournir des diagnostics spécifiques, par exemple signaler au développeur toutes les fonctions qui appellent fopen) sans tester son résultat ;

- effectuer un contrôle fin du typage, par exemple sous Gtk, le typage des arguments de la fonction variaire g_object_set ;

- faire des optimisations contextuelles, par exemple simplifier fprintf(stdout, ...) (éventuellement obtenu par expansion de macro ou par inlining de fonctions) en printf(...) ;

- aider à la navigation, le refactoring, la rétro-ingénierie, ou la métrique de gros logiciels sources ;

- et plus généralement, faire tous les traitements que vous imaginez qui profiteraient de la puissance de Gcc !

Ce genre d'extensions pourraient être fournies par des greffons péniblement codés en C. Ainsi, le projet Mozilla a fait, pour aider les développeurs du navigateur Firefox, le greffon TreeHydra (qui s'appuie sur Javascript) pour Gcc. Ce greffon permet de vérifier quelques règles de codage propres à ce projet.

Il existe aussi des analyseurs statiques autonomes, comme Frama-C (voir http://frama-c.com/), mais ceux-ci perturbent le cycle de développement (leur utilisateur doit lancer un outil autonome, au lieu d'ajouter des options à Gcc). Ce sont des outils très puissants, mais difficiles à utiliser, et adaptés à des cas particuliers (logiciels embarqués fortement critiques, notamment pour l'aéronautique ou le nucléaire). Il serait difficile d'utiliser Frama-C pour tous les logiciels usuels d'une distribution GNU/Linux, car il faudrait annoter, dans des commentaires utilisant le formalisme ACSL pour les spécifications et les propriétés du logiciel analysé, le code source de ces logiciels pour que Frama-C puisse en prouver la correction.

Le développement d'extensions de Gcc se heurte à plusieurs difficultés : d'abord et principalement, la complexité du compilateur Gcc ; d'autre part, les extensions doivent faire des traitements sur des données complexes - notamment trouver des motifs ou des formes particulières dans les représentations internes de Gcc, et le langage C (qu'on utilise pour coder des greffons) est peu adapté à ce genre de traitement.

MELT est un outil (disponible sur http://gcc-melt.org/, libre, sous licence GPLv3+) pour faciliter le développement d'extensions spécifiques de Gcc, en fournissant un langage dédié (domain specific language ou DSL, qu'on appelle aussi Melt) pour ce faire. Concrètement, après compilation et installation de MELT, on dispose d'un greffon melt.so pour Gcc 4.6. Il faut donc donner des arguments supplémentaires à gcc pour que MELT soit activé.

Le langage Melt a une syntaxe lispienne (dans la tradition d' Emacs Lisp ou de Guile). Une extension codée en Melt est d'abord traduite en un module MELT dynamiquement chargé par le greffon melt.so (qui appelle dlopen). Ce module est obtenu par génération de code C, ensuite compilé. Le traducteur de votre code Melt vers le code C ainsi généré est lui-même codé en Melt, et sa forme traduite en C est également distribuée (avec le code source Melt qui en est l'origine) dans l'archive source du logiciel libre MELT. À l'installation, la traduction du traducteur Melt vers C est recommencée.

L'utilisateur de MELT doit d'abord coder son extension en langage Melt. Ensuite, il doit faire générer par le greffon MELT le module correspondant, et ce module a été obtenu par compilation d'un fichier généré en C. Enfin, il va utiliser ce module, avec le greffon, pour compiler ses fichiers sources. On peut aussi faire exécuter du code Melt dans votre fichier passe.melt directement par le greffon ; dans ce cas, le greffon melt.so a chargé les modules du traducteur Melt qui ont automatiquement généré le (ou les) fichier(s) passe*.c, puis qui l'ont compilé (en lançant un make initié par gcc) en un module passe.so et l'ont chargé. Il faut donc éviter de nommer vos extensions Melt avec le même nom de base que les fichiers en C, C++, Ada, Go, ... que vous compilez avec.

Le programme gcc n'est qu'un programme lanceur qui, selon les suffixes des fichiers arguments, va lancer le compilateur proprement dit cc1 pour C, cc1plus pour C++, puis l'assembleur as sur le code produit, etc. Pour savoir ce que lance gcc, il faut lui passer l'argument -v.

L'article « Conception et vie d'un programme : les sous-traitants de Gcc » d'Alexandre Courbot (GNU/Linux Magazine France n°128, juin 2010, pages 34-42) détaille les programmes lancés par la commande gcc.

Comme les greffons de Gcc ne peuvent pas encore modifier le comportement du lanceur, il convient de compiler un fichier vide pour lancer Gcc avec MELT en tant que traducteur de votre code Melt. Ainsi, pour traduire votre passe.melt en un module MELT passe.so, il faut lancer la commande suivante (car techniquement, le traducteur MELT n'est pas un frontal de Gcc) :

Si on dispose d'un fichier vide empty.c, on peut lancer pour faire la même traduction :

Le traducteur de Melt vers C est rapide. Mais les commandes précédentes lancent automatiquement un make pour obtenir un module passe.so à partir des fichiers passe*.c générés. L'essentiel du temps est passé dans ce make interne, car le code C généré par MELT est souvent 20 fois plus gros que le code Melt qui en est à l'origine. En effet, Melt est un langage de haut niveau, concis et puissant. C'est là son principal intérêt !

2. Aperçu du langage Melt

2.1 Pourquoi un langage dédié lispien ?

Coder des extensions spécifiques à Gcc est difficile si on les code en C, car ce langage est très efficace, mais difficile à utiliser pour manipuler les structures de données internes, fort complexes, du compilateur. Il vaut mieux disposer d'un langage de plus haut niveau, plus expressif (même s'il est un peu moins efficace), et bien adapté aux traitements plutôt symboliques (sur des représentations internes arborescentes ou en graphe orienté) usuels à l'intérieur de tout compilateur. C'est particulièrement vrai quand on étend Gcc : l'extension (qu'elle soit un greffon natif laborieusement codé en C, ou une extension en Melt) sera utilisée moins fréquemment que Gcc et par une plus petite communauté d'utilisateurs ; aussi l'effort de développement de cette extension gagne à être diminué par l'utilisation d'un langage ad-hoc de haut niveau.

Il n'est pratiquement pas possible d'intégrer un langage de script existant (comme Python, Ruby, Lua, Guile, ou même Ocaml) dans le compilateur Gcc. En effet, ce compilateur n'a pas été conçu dans cette optique et contient de nombreuses structures de données (près de 2000 !) et des centaines de variables. La plupart des données (mais pas toutes) internes à Gcc sont gérées par un ramasse-miettes interne Ggc, très pratique mais rudimentaire, incompatible avec ceux des langages de scripts. Coller un interprète existant dans Gcc n'est pratiquement possible que si on se restreint à une minuscule partie des internes de ce compilateur, et la glue nécessaire serait rapidement obsolète avec l'évolution constante de Gcc, dont le code source croît encore de 6 % à 10 % chaque année...

La solution proposée par MELT est un langage ad-hoc, capable de manipuler aussi bien des données de Gcc que de MELT. C'est une distinction importante à faire : MELT propose ses propres types de données, qui sont typées dynamiquement (à la manière de Python ou Scheme) et gérées par le ramasse-miettes de MELT, on parle alors de valeur. Au contraire, il est parfois nécessaire de travailler sur les données élémentaires de Gcc, on parle alors de truc (ou de stuff en anglais). Dans la mesure du possible, on préfère généralement, dans du code Melt, manipuler des valeurs, mais il est indispensable de pouvoir aussi y traiter des trucs (comme les données gimple ou tree internes dans Gcc, ou tout simplement un long). Ce distinguo entre valeurs et trucs est essentiel dans MELT et constitue une originalité.

Il est aussi important de pouvoir insérer des bouts de code C dans du code Melt. Ceci permet d'utiliser facilement toute l'API interne de Gcc. C'est un peu l'analogue de la syntaxe asm dans le code C du noyau ; elle y apparaît rarement, mais on ne pourrait pas s'en passer. Le moyen le plus simple (de très bas niveau) d'insérer du C dans du Melt est l'opérateur code_chunk expliqué plus loin. Il existe aussi des constructions de plus haut niveau définissant comment transcrire vers le C des constructions en Melt.

L'avantage d'une syntaxe lispienne, c'est sa simplicité et son orthogonalité ; c'est aussi de disposer des nombreux outils qui la supportent (modes d'édition lispiens d'Emacs ou plugin Vim, par exemple, documentations, ...). L'étrangeté d'une syntaxe lispienne, c'est la multiplicité et l'importance des parenthèses (les mauvaises langues disent que Lisp est l'acronyme de « Lots of Insipid Stupid Parenthesis »). Mais on prend vite l'habitude des parenthèses. Il est recommandé d'éditer du code Melt avec un éditeur capable d'apparier rapidement une parenthèse ouvrante à sa fermante correspondante. Sous Emacs, on peut par exemple forcer le mode lispien d'édition en commençant chaque fichier source Melt par une ligne de commentaire ;; -*- lisp -*-. Un commentaire en Melt commence par un point virgule et termine à la fin de la ligne.

Tous les langages lispiens (dont Melt) partagent un même trait : les expressions sont toutes entre une paire de parenthèses, et l'opérateur est placé après la parenthèse ouvrante, suivi des opérandes et d'un parenthèse fermante. Ainsi, l'addition des trucs entiers 2 et 3 se code (+i 2 3) en Melt car l'addition entière y est l'opérateur primitif binaire +i. Les parenthèses sont toujours significatives en Melt : (f) est différent de f, car (f) est l'application (ou l'appel, ou l'invocation) de la fonction f sans arguments, tandis que f sans parenthèses est la valeur fonctionnelle (en Melt, les fonctions sont des valeurs à part entière). C'est la même distinction que f() (un appel de fonction) et f (le pointeur vers le code de la fonction) en langage C. D'ailleurs, ((+i 2 3)) est rejeté par le traducteur MELT, car on ne peut pas appliquer sans arguments le truc entier 5, qui n'est pas une valeur ! Les noms de variables (les symboles en jargon lispien) peuvent mélanger lettres et autres signes. On pourrait donc avoir une variable nommée a-b (qui n'est pas une soustraction, mais un identificateur, comme a_b peut l'être en C ou en Melt). La casse des lettres dans les symboles n'est pas significative (contrairement à C). Ainsi, +i est la même chose que +I; de même, if, If ou IF sont pareils. Les langages Scheme, Emacs Lisp, Common Lisp ont inspiré certains noms d'opérateurs essentiels de Melt comme if cond let letrec progn setq defun defclass, etc.

2.2 Quelques éléments de syntaxe en Melt

Le langage Melt est (comme Lisp, Scheme, Ocaml et d'autres) un langage construit sur des expressions qui sont évaluées en un résultat. Il n'y a donc pas d'instructions en Melt, seulement des expressions. Par exemple, la conditionnelle if renvoie un résultat (tout comme le fait l'opérateur conditionnel ternaire ?: du langage C). Ainsi, si x vaut le truc entier 2, l'expression (if (>i x 1) 3 (+i 1 x)) a pour résultat le truc entier 3. La même expression donnerait 1 si x était 0. Certaines expressions primitives renvoient un résultat vide et ne sont utiles que pour leurs effets de bord, par exemple un message de débogage. Il est aussi possible d'ignorer le résultat d'une expression. Par exemple, l'opérateur progn de Melt ignore le résultat de tous ses arguments, sauf le dernier (comme le fait la virgule dans une expression en C). Dans plusieurs constructions syntaxiques, une séquence d'expressions est évaluée en séquence, mais seul le résultat de la dernière sous-expression compte. C'est souvent le cas dans les branchements conditionnels, comme ici :

Il est possible d'avoir des variables locales en Melt. On utilise l'opérateur let suivi d'une séquence de liaisons (« bindings »). Ces liaisons sont locales au corps de l'expression let et y définissent donc des variables locales, inaccessibles à l'extérieur de ce let. Le corps du let est une séquence de sous-expressions dont la dernière renvoie le résultat du let alors que ceux des autres sont ignorés. Quand une liaison concerne un truc, pas une valeur, on y indique le type du truc par des « mots-clés » comme :long ou :gimple - les c-types de Melt. Ainsi, l'expression :

contient deux liaisons sur les variables locales x et y (de type truc entier) et son résultat est le truc entier 15.

Une faculté pratique de Melt est la possibilité d'inclure des fragments de code C dans du code Melt. Ces fragments sont les macro-chaînes (« macro-strings »). Alors qu'une chaîne de caractères entre double-accolades est lue en Melt comme en C de sorte que \n y est compris comme le caractère de saut à la ligne, une macro-chaîne commence par #{, et se termine par }#, mais l'antislash n'y est pas spécialement traité (car il est transcrit dans le code C généré). Le dollar signale et introduit une variable Melt dans une macro-chaîne. Cette astuce permet d'écrire naturellement des fragments de code C avec variables Melt. Ainsi, la primitive *i de multiplication de deux trucs entiers est définie par :

Dans une liste d'arguments formels, on donne des c-types (qui s'appliquent aux arguments suivants) et les noms des arguments. Ainsi, le premier :long qualifie les arguments a et b. Le deuxième :long qualifie le résultat de la primitive. On la documente par :doc. La macro-chaîne finale #{(($A) * ($B))}# décrit comment générer le code C associé à chaque utilisation de cette primitive et contient les deux variables a et b.

3. Écriture concrète d'un module en Melt

L'intérêt de MELT réside dans sa proximité avec Gcc, il va permettre de travailler facilement dans ses représentations internes et ses types. Il permet une certaine abstraction, mais nécessite tout de même que l'utilisateur comprenne les principaux ressorts de Gcc.

3.1 Les passes de Gcc

Les passes correspondent aux traitements successifs qui sont réalisés sur le code, il peut s'agir de transformation du code en une nouvelle représentation (GENERIC par exemple) ou de réaliser des optimisations sur le code. Il existe un grand nombre d'optimisations et de ce fait Gcc comprend un nombre impressionnant de passes.

Pour donner quelques exemples d'optimisations, elles peuvent être simples, comme supprimer le code mort, ou plus complexe à l'image de l'option mudflap, qui va ajouter des exceptions lors d'opérations délicates sur des pointeurs, pour protéger contre les overflows et autres opérations dangereuses.

3.1.1 Visualisation concrète dans Gcc

Gcc permet d'obtenir un fichier de dump pour chaque passe visualisée, on peut ainsi voir le résultat du code après transformation du code dans une forme ou une autre. Pour cela, on utilise la commande suivante :

Cette option permet de voir chaque passe exécutée au niveau middle-end. Selon le niveau d'optimisation auquel on travaille (-O0 pas d'optimisation particulière, -O1 quelques optimisations jusqu'à -O3 (optimisations importantes avec un travail long du compilateur)), on aura un nombre plus ou moins important de fichiers. Si l'on veut ne voir que le fichier ssa, on peut utiliser :

Il est également intéressant de regarder le fichier .vcg, il contient un format texte permettant de décrire le graphe de contrôle de la fonction. Basiquement, le graphe de contrôle permet de voir les différents blocs basiques (ensemble d'instructions séquentielles, c'est-à-dire sans conditions ni boucles) et les liens entre eux.

Grâce au logiciel vcgview (http://code.google.com/p/vcgviewer), on peut visualiser le graphe de différentes manières et sauvegarder l'image au format png.

3.1.2 Le désordre c'est l'ordre ?

Il est temps de soulever un point important sous Gcc : on ne sait pas à l'avance quelles passes vont s'exécuter et dans quel ordre cela se fera. On pourra donc lancer le programme avec les options de dumps pour voir les passes exécutées. Cependant, c'est peu satisfaisant, car selon les optimisations passées au code, ces passes peuvent changer. Attention encore, le format des fichiers dumpés est bien « nom_fichier_compilé.c.XXXt.ext » avec XXX un nombre et ext une extension. Cependant, le XXX correspond à un numéro statique associé à la passe, et ne donne pas d'indication concernant l'ordre d'apparition de celle-ci.

3.2 Les principales représentations

Comme nous l'avons vu, il existe de nombreuses représentations du code, nous allons détailler les principales au niveau middle-end :

- GENERIC : On la considérera comme la représentation la plus basique sur laquelle on pourra travailler, il s'agit d'un arbre syntaxique abstrait (en anglais AST, Abstract Syntax Tree). Il existe plus de 180 types de trees, dont le détail est donné dans le fichier gcc/tree.def. À noter également que cette représentation est générique quel que soit le langage source compilé.

- GIMPLE : Les déclarations GIMPLE sont des instances de type GENERIC avec davantage de restrictions, en particulier on parle de three-address code car les informations sont stockées sous la forme (opérateur, opérande1, opérande2). Un gimple représentera ainsi une instruction de notre programme. Le nombre de types est restreint à environ 35. Les différents types de GIMPLES peuvent être trouvés dans le fichier gcc/gimple.def. Cette représentation (définie dans gcc/gimple.h) est tellement centrale et tellement critique dans Gcc qu'il est peu probable de l'imaginer changer. En effet, ajouter un unique champ au type GIMPLE aurait une forte implication sur les performances et la mémoire consommée par Gcc.

- GIMPLE SSA : Très proche du GIMPLE, avec une particularité : une variable ne peut être associée qu'une et une seule fois. Pour cela, les variables sont divisées en « versions », les variables sont alors composées du nom original et d'une extension précisant la version.

- RTL : Register Transfer Language. Cette représentation bas niveau est utilisée dans la dernière partie du compilateur, qui génère le code assembleur. Nous ne traiterons pas de cette partie.

3.3 Utiliser MELT

3.3.1 Installer MELT

MELT est disponible sur http://gcc-melt.org. Il peut être installé sous deux formes : soit en tant que branche de Gcc, soit en tant que greffon à Gcc. Installer la branche nécessite de recompiler l'ensemble de GCC et s'avère parfois périlleux, cela permet de travailler sur la dernière version de MELT. Il est conseillé de commencer avec la version greffon, qui est plus stable et simple à utiliser. Cela nécessite de disposer d'un Gcc en version 4.6 ou supérieur. La liste des options à passer au compilateur lors de l'utilisation de MELT varie légèrement selon la version, l'article utilise le format de la version greffon, renseignez-vous si vous utilisez la branche. Un dernier point, Mandriva via le travail d'Alexandre Lissy a suivi de près MELT et dispose de ses propres paquets pour installer MELT de façon simple dans la Mandriva 2011. Vous pouvez donc choisir cette solution.

3.3.2 Un simple « hello world » avec Melt

Il est grand temps d'écrire son premier fichier Melt. Celui-ci ne sera pas d'une grande utilité, il permettra principalement de comprendre comment l'on insère du code Melt dans Gcc. Le fichier permettra d'afficher un « hello world » lors de la compilation.

Vous avez certainement compris qu'en Melt, le symbole; correspond à un début de commentaire. Vous retrouvez également la syntaxe Lisp vue précédemment. Ici, on définit une fonction say-hello-if à l'aide du mot-clé defun. Celle-ci prend 2 arguments (p et msg). p correspond à une value, donc une donnée propre à MELT, alors que msg est un truc, ici une chaîne de caractères C. Nous avons déjà vu le code_chunk permettant d'écrire directement du C. La dernière ligne représente un classique appel de fonction.

3.3.3 Compiler un module

L'étape suivante consiste à pouvoir compiler sous la forme d'une bibliothèque .so le module que l'on a créé. On va utiliser pour cela la ligne de code suivante :

MELT propose différents modes de fonctionnement. translatetomodule permet de convertir le fichier hello.melt en un fichier hello.c, à son tour compilé en une bibliothèque .so. On retrouve alors ce fichier dans le répertoire courant. Il est nécessaire de passer un fichier empty.c à compiler, sans quoi le compilateur renvoie une erreur. N'importe quel fichier (y compris un fichier vide) suffira et ne sera pas modifié.

Il est possible de voir le fichier C généré en utilisant translatefile plutôt que translatetomodule :

Désormais, on va pouvoir effectivement tester le module sur un fichier C de notre choix. Le mode noop ne fait rien d'autre que de laisser charger les bibliothèques et lancer leur exécution. -fmelt-init permet de déterminer le fichier .so à utiliser, -fmelt-module-path détermine dans quel répertoire se trouve le module.

Si tout s'est bien déroulé, vous devriez voir s'afficher dans votre terminal le fameux ''hello world''.

Il existe d'autres modes MELT, que je vous invite à explorer. Pour connaître leur liste et leurs fonctions, il suffit de taper :

3.3.4 Une véritable passe

Notre hello world était amusant, mais pour autant, il n'a pas travaillé sur le code C que l'on cherche à compiler. Il est temps d'écrire une passe qui soit capable d'étudier le code du fichier passé au compilateur. Ce sera l'occasion de découvrir les dernières fonctionnalités de MELT.

Voici un exemple permettant de comprendre le genre de module qu'il est possible d'écrire. Vous connaissez certainement la fonction C fopen() qui permet d'ouvrir un fichier. Elle retourne un pointeur sur un FILE. C'est évidemment une bonne pratique que de tester que ce pointeur n'est pas NULL plutôt que d'avoir de mauvaises surprises par la suite. Nous allons donc voir les différentes étapes pour écrire une passe vérifiant (de façon naïve, fonctionnant dans le cas courant) que la fonction est bien testée.

3.3.4.1 Définir sa passe

Cette fonction permet de déclarer la passe et de définir ses attributs. On remarque ici que l'on travaille sur une passe se faisant au niveau GIMPLE (on instancie un objet de la classe class_gcc_gimple_pass). On donne un nom à notre passe, melt_test_fopen (ce nom sera utilisé dans les fichiers de dump), on explicite une fonction gate, cette fonction servira à expliquer sous quelles conditions on exécute la passe ou pas (en pratique, ça peut être selon que des options d'optimisation soient appelées ou non, cela peut également être par rapport à des informations sur le code). gccpass_exec définit la fonction qui réalisera le traitement de la passe. gccpass_data permet de stocker des éléments propres à la passe. En général, on va stocker dans gccpass_data l'arbre de la fonction.

Parfois, une passe peut nécessiter certaines propriétés pour s'exécuter, ici on ne s'en occupera pas.

La dernière partie concerne la position à laquelle on insère la passe dans Gcc. Comme nous l'avons vu, il est difficile de connaître l'ordre d'exécution des passes. Souvent, on a un ordre d'idée de la position à laquelle on veut insérer sa passe, cela peut être au niveau de la représentation SSA comme ici. Ensuite, il vaut mieux tester que la passe dispose des bonnes informations pour s'exécuter et qu'il n'y a pas d'incompatibilités avec les autres passes.

3.3.4.2 Définir un mode

Nous avons déjà vu un certain nombre de modes (en particulier translatetomodule), dans le cas général, l'utilisateur va vouloir ajouter ses propres modes pour lancer ses passes particulières. Pour ajouter un mode, il suffit de déclarer une instance de la classe class_melt_mode Elle comprend un nom (sous la forme d'une value), une aide et une fonction principale, ici test_fopen_docmd, que nous venons d'analyser et qui est appelée au lancement du mode. La fonction install_melt_mode permet d'installer effectivement le mode.

3.3.4.3 Fonction Gate

On doit définir la fonction gate que nous avons utilisée dans test_fopen_docmd. Si cette fonction retourne NULL, on ne passera pas plus loin dans la passe, si cette fonction retourne autre chose, on exécute la passe. La fonction présentée ici est triviale et retourne toujours quelque chose de non NULL.

3.3.4.4 Déboguer dans Melt

L'usage de la fonction debugtree permet de mettre en valeur la façon dont on peut déboguer du code Melt et comprendre la structure des données dans Gcc. En effet, si lors de la compilation, on passe l'argument -fmelt-debug, on aura tout un ensemble d'informations de debug qui sortiront sur la sortie d'erreur. Ce flux est important et certaines informations ne sont pas utiles aux simples utilisateurs, mais cela permet tout de même souvent de comprendre une erreur et d'observer la structure des arbres et gimples.

Par exemple, on trouvera comme information :

Ici, hello et main correspondent à deux fonctions du programme que l'on compile. On constate donc que la passe est appelée successivement pour chaque fonction que l'on compile. Le détail n'est pas donné, mais l'on peut obtenir des informations sur la fonction, son type retourné, ses arguments.

3.3.4.5 Fonction exec

On va maintenant pouvoir s'attaquer au cœur de notre passe, la fonction exec qui correspond à l'exécution de la passe.

cfun_decl est une primitive (traduite en une variable C) donnant la fonction courante inspectée par la passe. On vérifie ici à l'aide d'information de debug que l'on entre bien dans la passe et que cfun_decl est bien présent. Le gros du travail est laissé à la fonction detect_untested_fopen. Pour la comprendre, nous avons encore besoin de deux concepts de Melt : les itérateurs et le pattern matching.

3.3.4.6 Les itérateurs

Melt reprend le concept des itérateurs du C++ (ou du Java d'ailleurs) et fournit en particulier un ensemble d'itérateurs sur les structures classiques de Gcc. On trouve ainsi des itérateurs sur les blocs d'instructions, sur les gimples ou encore sur des maps d'objets. Ces itérateurs sont définis dans les sources de MELT (répertoire gcc/melt) via l'opérateur defciterator, ils commencent généralement par un foreach ou each. La fonction detect_untested_fopen utilise each_bb_current_fun qui permet d'itérer sur l'ensemble des blocs basiques de la fonction. L'élément courant dans l'itération est bb. Elle utilise ensuite eachgimple_in_basicblock pour itérer sur chacun des gimples de bb.

3.3.4.7 Le pattern matching(filtrage par motif)

Nous avons gardé le meilleur pour la fin, c'est en effet une des fonctionnalités les plus importantes de MELT. Elle peut ressembler aux expressions régulières type posix, sauf qu'ici on ne travaille pas sur des textes, mais bien sur les gimples qui ont une structure de données plus complexe (ou d'autres structures en arbre de Gcc). Le pattern matching est effectué via l'expression match, il faut avant tout préciser l'objet que l'on souhaite analyser (ici il s'agit de g, notre gimple), ensuite on va placer successivement un ensemble de patterns (filtres). Chacun de ces filtres va d'abord lancer un test sur l'objet matché afin de vérifier certaines caractéristiques, et si le test réussit, on va alors instancier un ensemble de variables. Un pattern commence toujours par le symbole ?.

Prenons le premier exemple de matcher : nous cherchons à matcher les appels à la fonction fopen qui prend deux arguments, on a donc une instruction de la forme :

Cette expression est matchée par la fonction detect_fopen suivante :

Le matcher gimple_call_2 signifie que l'on va chercher un appel à une fonction à 2 arguments (on aurait pu utiliser un matcher qui ne s'occupe pas du nombre d'arguments, mais préciser le nombre d'arguments permet de récupérer facilement les variables à instancier si le test réussit). ?lhs signifie que l'on a un matcher sur la partie gauche de l'expression (ici, on ne précise rien de plus, ne posant pas de condition). Par contre, concernant l'appel de fonction lui-même (callfndcl), on va demander à ce que la déclaration de la fonction (tree_function_decl) vaille la chaîne "fopen". ?arg1 permet de récupérer le premier argument de la fonction dans une variable arg1, de même pour ?arg2 avec le second argument. Nous ne nous servons pas ici de ces arguments, par contre on renvoie lhs, nous devrons en effet, par la suite, vérifier qu'il n'est pas NULL. Le deuxième pattern (?_) est le pattern joker, il match toujours. Il permet ici de renvoyer un null_tree si l'on n'a pas matché d'appel à fopen.

De la même façon, nous écrirons une fonction detect_cond_with_null permettant de détecter que le gimple suivant représente bien une condition valide. Il existe un ensemble de matchers permettant de détecter les différents types de conditions (par exemple gimple_cond_equal ou gimple_cond_greater). Il faut également vérifier que le tree utilisé dans la condition est bien le même que celui représentant le résultat de l'appel à la fonction fopen (ce que l'on fait dans detect_untested_fopen à l'aide de l'opérateur ==t).

3.3.5 Testons notre module

Une fois le module écrit, il ne vous reste plus qu'à le tester. Écrivez un nouveau fichier C simple utilisant fopen (en omettant de tester le résultat de l'appel), par exemple le suivant :

Compilons le module melt :

Compilons le fichier C, tout en appliquant notre module :

Si tout s'est bien passé, nous devrions voir l'avertissement suivant :

Libre à vous d'étendre le module à des cas plus complexes et de le tester sur de véritables programmes.

3.4 pour finir

Cet exemple devrait vous donner des idées d'utilisations possibles de MELT. Ici, l'exemple est simple et incomplet, mais on peut imaginer des programmes plus complexes : en particulier en travaillant sur les différents appels de fonctions. Cela peut être un moyen d'ajouter un ensemble de diagnostiques ou de métriques. MELT est toujours en évolution, pour l'instant il est encore difficile de l'utiliser pour réaliser des optimisations (modifications des gimples ou autres représentations de Gcc), mais on peut imaginer l'étendre pour cela. Vous pouvez également trouver un exemple de module écrit en MELT permettant de réaliser des tests proches de celui présenté ici, mais de façon plus complète et facilement paramétrable par l'utilisateur : talpo.pvittet.com.

Le site gcc-melt.org contient aussi des documents (souvent en anglais) décrivant MELT avec plus de détails. Il existe aussi un groupe de discussion gcc-melt (en anglais) sur GoogleGroups.