Sortie de TinyCC 0.9.26

TinyCC est un compilateur C léger et rapide qui, en plus de ces qualités, a deux particularités originales :

1. il permet de compiler et d'exécuter du code à la volée (option -run) ;
2. en plus de l'exécutable, il est disponible sous forme de bibliothèque (libtcc) afin d'être embarqué dans d'autres programmes.

TinyCC a été écrit à l'origine par Fabrice Bellard, qui ne participe aujourd'hui plus à son développement. Les nouveaux développements sont assurés par une communauté de développeurs organisés autour d'une liste de diffusion et d'un dépôt Git dont l'une des branches est ouverte aux publications externes. Le vendredi 15 février 2013, l'un de ces développeurs, Thomas Preud'homme a annoncé la sortie d'une nouvelle version du compilateur, estampillée 0.9.26. Nous avons posé quelques questions à Thomas, dont les réponses figurent en deuxième partie de dépêche après l'exposé des nouveautés de cette version.

Sommaire

• Modifications importantes depuis TinyCC 0.9.25
  • Interface utilisateur
  • Plates-formes
  • Fonctionnalités
• Interview de Thomas Preud'homme

Modifications importantes depuis TinyCC 0.9.25

Ceci est une traduction de la note de version officielle.

Interface utilisateur

• Option -MD/-MF (génération automatique de dépendances pour make) (Kirill Smelkov)
• Option -pthread (identique à -D_REENTRANT -lpthread) (Henry Kroll III)
• Options -m32 et -m64 pour réexécuter le compilateur croisé (Henry Kroll III)
• Support par l'option -Wl de toutes les formes d'options supportés par GNU ld (Kirill Smelkov)
• Ajout de la fonction tcc_set_options() à l'API de libtcc (grischka)

Plates-formes

• Beaucoup d'améliorations pour les cibles x86-64 (Shinichiro Hamaji, Michael Matz, grischka)
• Assembleur x86-64 (Frederic Feret)
• Beaucoup d'améliorations pour les cibles ARM (Daniel Glöckner, Thomas Preud'homme)
• Support des systèmes Windows CE PE ARM (Timo VJ Lahde)
• Support de la convention d'appel des fonctions « ARM hardfloat » (Thomas Preud'homme)
• Support de SELinux (Security-Enhanced Linux) (Henry Kroll III)
• Support des systèmes Debian GNU/kFreeBSD (Pierre Chifflier)
• Support des systèmes GNU Hurd (Thomas Preud'homme)
• Support de MacOS X (tcc -run seulement) (Milutin Jovanovic)
• Support des configurations multi-architectures (Thomas Preud'homme)
• Support de la compilation hors-arborescence (Akim Demaille)

Fonctionnalités

• Tableaux à longueur variable C99 (Thomas Preud'homme & Joe Soroka)
• Étiquettes assembleur pour les variables et fonctions (Thomas Preud'homme)
• STT_GNU_IFUNC (fonctions dont l'adresse est résolue par l'appel d'une autre fonction) (Thomas Preud'homme)
• Plus de tests (tests2) (Milutin Jovanovic)

Interview de Thomas Preud'homme

Thomas Preud'homme, connu sur LinuxFR sous le pseudonyme robotux, termine actuellement une thèse au Laboratoire d'Informatique de Paris 6 (LIP6), intitulée « Communication inter-cœurs optimisée pour le parallélisme de flux ». Contributeur au projet Debian depuis plusieurs années, il est responsable de plusieurs paquets, dont TinyCC (paquet tcc), et est devenu développeur Debian depuis peu.

DLFP : Bonjour Thomas. Peux-tu nous en dire plus sur l'histoire de TinyCC ?

Je n'en sais pas beaucoup plus que ce qu'on peut trouver sur Internet. Tout a commencé sous la forme d'un bout de code soumis par Fabrice Bellard au concours international de code obscur IOCCC, appelé OTCC (pour Obfuscated Tiny C Compiler, minuscule compilateur C obscurci). Par la suite, Fabrice a ajouté le support du format de binaire ELF (Executable and Linkable Format) renommant au passage le programme en OTCCELF. Enfin, il a réécrit le compilateur sous la forme de TinyCC afin de le rendre plus lisible, améliorant au passage le support du C.

Le développement de TinyCC s'est arrêté plusieurs fois après que Fabrice ait cessé de maintenir TinyCC. Ce sont ces pauses dans le développement qui ont mené (à ma connaissance) au développement du fork de Rob Landley. Chaque fois, les changements apportés par Rob étaient réintégrées dans TinyCC relançant brièvement le développement de celui-ci. Lorsque cela se produisait, Rob cessait alors le développement, n'en ressentant plus l'utilité, ce qui provoquait une nouvelle pause dans le développement de TinyCC. Ce développement chaotique a eu raison de la patience de Rob qui a fini par ne plus vouloir contribuer à TinyCC. Il s'en est expliqué sur son site. Rob s'intéresse maintenant à la création d'une boîte à outils pour la compilation qui réutiliserait la partie génération de code de Qemu, supportant ainsi toutes les architectures que supporte Qemu.

Au fil des versions, TinyCC s'est étoffé : il supporte maintenant plusieurs architectures (x86 32 et 64 bits, ARM pour diverses conventions d'appel, Texas Instrument TMS320C67xx et .NET CLI), plusieurs plates-formes (Linux, Windows, (k)FreeBSD, et support partiel de Hurd et MacOS X).

DLFP : Qui contribue au développement de TinyCC ? La liste des contributeurs pour cette version comporte plusieurs dizaines de noms. Est-ce une habitude ? Le développement est-il essentiellement assuré par un noyau de contributeurs réguliers, ou les contributions ponctuelles sont-elles les plus fréquentes ?

Je ne sais pas très bien qui sont les contributeurs de TinyCC. Mon impression est que les contributeurs se divisent plus ou moins en deux catégories. Il y a d'une part ceux qui s'intéressent aux compilateurs : ceux-ci préfèrent TinyCC car sa petite base de code est plus facile à étudier et parce que la branche de développement est ouverte à tous, permettant de partager plus simplement leurs expérimentations. Ceux-ci sont plutôt des contributeurs réguliers. D'autre part, il y a ceux qui ont rencontré un bogue avec TinyCC et qui cherchent à le corriger. Cela peut se traduire dans des contributions importantes lorsque la personne rencontre plusieurs bogues ou que c'est un problème assez essentiel dans TinyCC. Il s'agit alors de contributions plutôt ponctuelles.

Le nombre de contributeurs pour cette version est exceptionnellement élevé. D'après l'historique, le nombre de contributeurs n'a cessé de croître, ce qui est plutôt encourageant. Cependant le nombre de contributeurs pour cette version s'explique aussi par la période particulièrement longue pour arriver à cette nouvelle version. Il a fallu 3 ans pour développer celle-ci, là où les versions précédentes ne prenaient qu'un an en moyenne.

DLFP : Tu as toi-même produit un certain nombre des changements qui ont mené à cette nouvelle version de TinyCC. Quand et comment as-tu commencé à contribuer ? Qu'est-ce qui t'intéresse particulièrement dans ce projet ?

J'ai commencé à m'intéresser à TinyCC un peu par hasard. Utilisateur de Debian depuis plusieurs années, je souhaitais commencer à contribuer en retour, en partie pour montrer ma reconnaissance sur tout ce que j'ai pu retirer de ce projet. Je connaissais Aurélien Gérôme, qui était sur le point de devenir développeur Debian, et il m'a proposé de maintenir TinyCC avec lui. Ce programme étant écrit dans mon langage de prédilection (le C) et étant intéressant pour moi, j'ai accepté. Je n'utilisais alors pas TinyCC et j'ai commencé à l'utiliser à cette époque.

Peu actif au début, j'ai fini par me retrouver tout seul à maintenir le paquet. La majeure partie des bogues, pour ne pas dire tous, étaient liés à des problèmes du logiciel et non de l'empaquetage. J'aurais pu me contenter de transmettre les bogues aux développeurs amont mais je ne pouvais résister à l'envie d'essayer de les corriger moi-même. J'ai donc commencé sur ceux qui correspondaient à des problèmes bien isolés.

J'ai pris beaucoup de plaisir à corriger ces bogues car je n'avais jamais suivi de cours de compilation et ai donc appris en lisant le code. TinyCC n'est pas le meilleur exemple en la matière certes, mais le code est relativement petit et donc plus simple à comprendre. Le code est d'autant plus simple qu'il n'y a pour ainsi dire pas d'optimisation du code généré. Cela rend évidemment le code moins efficace mais rend la compilation plus rapide et surtout, pour ce qui nous concerne, le code de génération plus simple à lire. De plus, je suis globalement intéressé par tout ce qui est bas niveau : noyaux, compilateurs, chargeurs dynamiques, etc. Travailler sur TinyCC m'a permis d'apprendre beaucoup dans ce domaine.

DLFP : Comment en es-tu venu à être responsable de la publication de cette version ? Penses-tu t'occuper des prochaines versions également ?

Un jour, on m'a soumis un rapport de bogue visant à supporter une nouvelle convention d'appel (la façon dont sont appelées les fonctions, en particulier comment sont passés les paramètres) pour l'architecture ARM. Le patch m'a demandé beaucoup de temps : il m'a fallu d'abord comprendre le problème, ensuite apprendre la nouvelle convention d'appel, me familiariser avec le code gérant l'ancienne convention d'appel puis enfin effectuer l'implémentation et déboguer le tout. Une fois le patch fini je me suis alors rendu compte qu'il fallait également ajouter le support de nouvelles relocations (une relocation est un processus consistant à calculer l'adresse finale d'une fonction ou d'une variable et à mettre à jour tous les endroits dans le code référençant ces éléments).

J'ai également trié les rapports de bogues sur Savannah (le service GNU qui héberge le site de TinyCC) et ai globalement été prompt à répondre aux rapports de bogues tant dans Debian que sur la liste de diffusion. J'ai aussi cassé TinyCC de nombreuses fois mais ai toujours été là pour réparer et au final personne ne m'a fait de reproches.

Au travers de tous ces petits patches et de la plus grosse série que constitue le support de la nouvelle convention d'appel, j'ai donc fini par me faire remarquer de la personne ayant été responsable des deux dernières publications de TinyCC : Grischka. Par exemple, après avoir demandé plusieurs fois de mettre à jour la branche principale par rapport à la branche de développement (lorsque celle-ci était stable), cette personne a fini par me donner les droits de commit sur celle-ci. De la même façon, à force de suggérer qu'on devrait enfin faire une nouvelle publication, cette personne m'a suggéré que je devrais la faire.

La publication a pris plus longtemps que je ne le pensais et en particulier m'a demandé plus d'efforts que je ne le pensais. En effet, je voulais être sûr que tout fonctionne correctement, aussi ai-je fait un appel à tests. J'ai été agréablement surpris, mais aussi un peu débordé, de voir autant de réponses. Ces réponses m'ont permis de découvrir de nombreux bogues que je ne soupçonnais pas et nous a permis de les corriger. Bien que cela ait pris du temps, le résultat est pour moi beaucoup plus satisfaisant car je sais que la qualité est meilleure ainsi. Je recommencerai donc avec plaisir la prochaine fois en essayant de laisser moins de temps s'écouler d'ici là. J'aimerais qu'on fasse une publication par an environ, voire tous les un an et demi. Le faire plus souvent serait inutile car le développement n'est pas très rapide pour l'instant.

DLFP : Peux-tu expliquer comment se déroule un cycle de publication de TinyCC ?

Je ne peux pas répondre pour les cycles précédents car je ne suivais pas le développement de près. En ce qui concerne ce cycle, il n'y a pas eu de processus bien défini pour la simple raison que ce n'est à mon avis pas nécessaire pour le moment : la participation est encore faible et il n'y a que très peu de contributeurs réguliers. Si la participation augmente, un processus se mettra en place. Pour l'instant, les gens contribuent lorsqu'ils en ont l'envie et le temps et la publication se fait quand quelqu'un le décide. De plus, je n'ai su qu'assez tard que ce serait moi qui ferais la publication, environ 2-3 mois avant la publication elle-même.

Cependant, dès qu'il m'a été suggéré de m'en occuper, j'ai annoncé mon intention de faire une nouvelle publication et ai fait un appel à tests. J'ai alors pris le temps de lire chaque rapport de bogue et ai essayé d'en corriger le plus possible. Grischka, qui a effectué les deux publications précédentes, a été d'une aide très importante en me suggérant des commits à défaire car (i) effectuant de trop grosses modifications, (ii) encore un peu instables ou (iii) non souhaitables dans TinyCC (typiquement les fonctionnalités ajoutant le support de l'optimisation à TinyCC, qui le rendent plus lent à compiler). Daniel Glöckner a également participé en corrigeant plusieurs bogues concernant l'architecture ARM avant que je n'aie eu le temps d'y regarder de plus près.

Est venu enfin le temps de la publication à proprement parler. Pour que celle-ci se fasse un choix a dû être fait concernant la présence de bogues connus. En effet, quelques jours avant de publier la nouvelle version il a été découvert que TinyCC ne parvient pas à compiler des projets faisant usage de fonctions variadiques (fonctions ayant un nombre variables d'arguments) lorsque la bibliothèque de gcc (libgcc_s) est utilisée. Devant l'incertitude concernant le temps nécessaire pour régler ce problème, il a donc été décidé de procéder à la publication en l'état. Cette nouvelle version apporte tout de même de nombreuses nouveautés et corrige beaucoup de bogues.

DLFP : Y a-t-il déjà des plans quant aux fonctionnalités prévues pour la prochaine version de TinyCC ? Et à plus long terme ?

Il n'y a pas de plan au niveau du projet dans le sens où on se mettrait d'accord sur une liste de fonctionnalités à ajouter. Les ajouts se font en fonction des motivations de chacun, de façon non coordonnée. Étant donné le faible nombre de contributeurs réguliers, il me semble à la fois trop ambitieux et inutile de décider d'une feuille de route pour TinyCC. De plus, il me semble que même parmi les contributeurs réguliers il n'y a pas d'idée précise de la direction vers laquelle nous souhaitons faire évoluer TinyCC.

En revanche, j'ai une liste personnelle de changements que j'aimerais voir dans TinyCC. Cette liste est trop longue pour que tout soit réalisé en un an sur mon temps libre aussi seule une partie de ces changements verra le jour dans la prochaine version. Le reste sera donc reporté aux versions suivantes. Par contre je ne peux encore vous dire quels changements seront effectués en premier. Voici la liste :

Correction de bogues

• synchronisation des caches de données et d'instructions avant d'exécuter un programme compilé (fait)
• création de la bibliothèque libtcc1.a pour l'architecture ARM avec :
  • les divisions entières (idiv, idivmod, uidiv, uidivmod)
  • la fonction __clear_caches nécessaire pour assurer la synchronisation entre les caches d'instructions et de données
  • les opérations en virgule flottante (nécessaires pour la convention d'appel ARM EABI)
  • les autres fonctions requises pour la convention d'appel ARM ABI
• permettre à tous les tests de passer sur kFreeBSD et Hurd
• corriger l'édition de lien pour que objdump et gdb acceptent de lire les exécutables produits sans l'option -g
• ajout de la génération de code PIC (indépendant de la position finale)
• réécriture plus propre de la convention d'appel ARM hardfloat
• détecter lorsqu'une fonction est déclarée statique mais définie non statique (et vice versa)
• rendre les accolades optionnelles dans les structures imbriquées comme requis par le standard C99
• prise en compte du code de retour de parse_btype dans la fonction struct_decl
• corriger certains des bogues déclarés sur Savannah

Ajout de fonctionnalités

• choix de la convention d'appel à l'exécution pour les architectures ARM 32 bits
• support de l'architecture ARM 64 (aussi connue sous le nom de ARMv8 ou aarch64)

DLFP : Y a-t-il quelque chose que tu voudrais ajouter ?

Je souhaiterais remercier encore une fois l'ensemble des personnes ayant contribué à la réalisation de cette nouvelle version de TinyCC. Je souhaite en particulier remercier Grischka qui a travaillé au moins autant que moi sur cette nouvelle version. Son expertise sur le code est plus grande que la mienne et ses remarques et patches ont été déterminants pour sortir cette nouvelle version.

J'invite aussi les lecteurs de LinuxFr.org qui s'intéressent aux compilateurs à jeter un œil à TinyCC. Comparé à LLVM/clang ou GCC, TinyCC est très petit et donc plus facile à appréhender. De plus, il est très facile d'y contribuer et il reste de nombreuses contributions simples à faire. Je ne connaissais rien à la compilation lorsque j'ai commencé à étudier TinyCC et j'ai appris énormément depuis.

DLFP : Merci beaucoup, Thomas, d'avoir pris le temps de répondre à ces questions (et de m'avoir aidé à traduire la liste des changements !).

Aller plus loin

• Page officielle de TinyCC (507 clics)
• Page Savannah (84 clics)
• Annonce de la sortie de TinyCC 0.9.26 (55 clics)