Transcription

Basile Starynkevitch : Je vais vous parler du projet GlobalGCC sur lequel je bosse à temps plein. Bon, c’est un projet de R&D européen, "européen" entre guillemets car dans le cadre ITEA. C’est une direction européenne mais il y a un financement multinational : moi je suis financé par le contribuable français et pas par le contribuable européen. Il y a une douzaine de partenaires,donc je vais en citer quelques uns.

Donc, l’objectif du projet, c’est d’étendre le compilateur GCC, qu’un certain nombre d’entre vous connaissent parce que vous l’utiliser pour compiler du code source, par des techniques d’analyse statique de code pour aider le développeur. L’analyse statique du code source, c’est le boulot que je fais depuis un certain nombre d’années. Ça consiste à calculer des propriétés du code source sans exécuter le programme.

Ça permet quoi ? Alors, c’est des techniques compliquées et coûteuses, compliquées car y’a des maths derrières, c’est compliqué à coder. Les premiers analyseurs statiques propriétaires tournaient pendant des mois de CPU, (rires) ce qui change du temps qu’on fait [prend] sur un "compiler" [NdT. bouton ou action de lancer la compilation]. En particulier, j’ai eu un feedback un peu négatif sur la mailing list GCC quand j’ai annoncé le projet. Quand j’ai dit : « Au minimum, je vais être dix fois plus lent que le compilateur », les gens ont tiré la gueule. Néanmoins certains sont intéressés par ça, car l’idée c’est qu’on veut obtenir un diagnostic fin : "Attention à telle ligne vous aurez une violation de pointeurs, si vous êtes appelé par telle fonction, avec une variable qui vaut tant, etc". Autrement dit, c’est un sorte de débuggueur avant d’exécuter le programme. Alors bien sûr, ce n’est pas magique, y’a des théorèmes de limitation qui s’appliquent, on ne résout pas le problème de la règle de la machine de Turing. Néanmoins, c’est un outil complémentaire qui peut aider. Donc on calcule des propriétés. Ça permet soit un diagnostique fin, comme je viens de l’expliquer, soit des optimisations globales fines et, comme je viens de le dire, c’est coûteux en temps.

Il y a un autre aspect du projet sur lequel je ne travaille pas, mais qui est très intéressant aussi, c’est la vérification des règles de codage. On exprime des règles de codage sous un formalisme, du genre : les règles les plus simples, c’est des règles purement syntaxique du genre "les fonctions doivent tenir sur l’écran", ça c’est simple mais on peut aussi avoir des règles du genre "il ne peut pas y avoir d’héritage virtuel dans tel et tel cas, et cetera".

Alors les difficultés, que j’avais un peu évoquées, mais je le répète, elles sont plus grandes que ce qu’on croit :
* Difficultés techniques de compilation parce qu’un compilateur c’est compliqué. Pour info s’il y a des jeunes ici qui sont intéressés par le domaine, c’est un domaine qui est croissant, c’est un domaine où il y a un certain nombre de partenaires qui cherchent à embaucher des gens et qui n’y arrivent pas. Notamment à l’INRIA, ils ont des postes d’ingénieurs experts ouverts, et cetera ;
* Difficultés à appréhender un gros programme de 3 millions de lignes, parce que apprendre, enfin comprendre GCC, ça prend toujours plus de temps qu’on ne croit, même en tenant compte de la loi de Hofstadter. Il a fallu bâtir une infrastructure lourde en plus. Y’a des techniques qu’on met en œuvre qui sont complexes : l’interprétation abstraite par exemple, et comme je l’ai évoqué il y a quelque temps, les outils propriétaires équivalents qui existent depuis quelques années,et sont extrêmement chers. C’est à dire PolySpace par exemple, je ne connais pas le prix de la licence mais le CEA ne peut pas se le payer (rire). Je crois que c’est 50 000 ou 100 000 euros par poste.

Qu’est-ce qu’on a comme résultats actuels et futurs ? D’une part, un résultat important c’est que GCC qui est assez américain, y’a un peu plus d’européens qui travaillent dessus. Y’a des validations de règles de codage qui existent. Y’a des formalismes qu’on met en place en plus. Enfin, moi j’ai passé pas mal de temps à faire un dialecte lispien pour exprimer des algorithmes d’analyse statique. En optimisation adaptative, y’a déjà des premiers résultats qui sont extrêmement intéressants et ils peuvent optimiser, parfois un facteur, deux ou trois mieux que ce que fait GCC avant certaines routines très particulières de décodage vidéo notamment. Alors l’adresse est là et n’oubliez pas le www sinon vous tombez sur une page chez Mandriva qui n’a rien à voir. Éventuellement, on cherche des testeurs. Je pense qu’un résultat futur espéré, c’est de vulgariser ces techniques d’analyse statique dans un monde plus large. Pourquoi ? : Parce qu’actuellement les outils d’analyse statique sont chers et, en pratique, ne sont utilisés que dans les gros services d’assurance qualité ou de recette des gros industriels, et si on met ça sur le poste du développeur, et ben ça va vulgariser un petit peu.

Je crois que j’ai fini, je suis ouvert aux questions.

applaudissements

Tangui Morlier : Est-ce que moi, développeur libre, j’aurais intérêt à utiliser Global GCC et quels sont les intérêts ? Est-ce de la sécurisation du code ou est-ce que mon application compilée avec ton adaptation de GCC sera plus rapide et efficace ?

Basile Starynkevitch : Les deux.

Tangui Morlier : Est-ce que tu as des chiffres ?

Basile Starynkevitch : Non, parce qu’il n’y a rien qui ne tourne complètement. On en est encore au développement.

Tangui Morlier : Donc dans un futur proche, j’aurais intérêt.

Basile Starynkevitch : La validation de règles de codage, ça commence à tournicoter déjà. L’analyse statique, ça tournicote pas encore, mais je m’en approche. Donc la réponse est double. Alors moi, je vais généraliser : c’est "Pourquoi on utilise des outils d’analyse statique ?". Je suis dans un labo qui en fait depuis des années. J’ai travaillé préalablement dans des éditeurs propriétaires. Pourquoi on utilise des outils d’analyse statique ? Pourquoi des boîtes comme EdF, Airbus s’en servent ? D’abord dans le domaine du logiciel critique embarqué, c’est à dire celui qui contrôle les barres de commande, celui qui contrôle les ailes d’un avion, c’est des logiciels : on imagine pas du tout ce que c’est. Moi j’en vois très peu parce que je suis plutôt dans l’analyse pour ces trucs là, mais je les vois assez peu. C’est des logiciels critiques, c’est coûteux à développer, c’est souvent du code généré et on est prêt à dépenser des millions pour être sûr que quand l’avion veut atterrir : il atterrit et que quand la barre de contrôle du réacteur veut descendre, elle descend. Là, l’industriel qui finance le truc, il a tellement besoin de ça, il est tellement angoissé qu’il a payé des millions pour être sûr que ça se passe. Il y a des tas de façons : soit analyse statique, soit des méthodes de tests très compliqués, souvent les deux ensembles, etc. Mais l’intérêt pour un développeur, par exemple : trouver des bugs de débordement de tampon dans un patch, c’est quelque chose qui est à peu près envisageable. Ça trouvera des bugs simples de ce genre là, mais je t’assure que c’est utile, ou le bug tout simple que j’ai déjà fait, tu déclares un tableau T de 4 et tu accèdes au 4ème élément alors qu’il ne fallait accéder qu’au 3ème, c’est un bug que j’ai fait y a encore trois mois. Et donc un truc qui en compilant dix ou cinquante fois plus lentement, c’est un truc que tu lanceras la nuit ou en allant bouffer parce-que c’est un make un peu particulier, tu feras make CC=ggcc au lieu de make CC=gcc, ou un truc comme cela . Moi je pense qu’un outil qui dans un certain nombre de cas te trouve des bugs simple comme ça, il trouve pas tous les bugs évidemment, mais ça permet de donner des diagnostics sur des bugs simples comme ça, je pense que pour le développeur, il sera content de l’avoir.

Tangui Morlier : Et pour l’optimisation ?

Basile Starynkevitch : Pour l’optimisation, c’est pas moi qui travaille en détail, c’est l’INRIA, mais il y a des routines de codec vidéo qu’ils optimisent avec un gain de perf de 3.

Tangui Morlier : D’accord.

Lionel Allorge : J’ai raté en fait le principe général, vous analysez le code source de GCC ?

Basile Starynkevitch : Non, on adapte, on étend GCC en mettant des modules en plus pour que l’application que tu compiles avec, dont tu disposes du code source, soit analysée plus finement.

Lionel Allorge : Est-ce que vous avez fait de la rétroaction, est-ce que vous avez analysé le code de GCC avec ?

Basile Starynkevitch : Non, la réponse avec les analyseurs précédents qu’on a fait, est non. Pourquoi ? Parce que GCC est vraiment énorme. Grosso-modo, par exemple, tu vas avoir des temps de calcul, au lieu d’être en n, ils sont en n^2 sur la taille du code, pour 100 000 lignes, ça passe ; pour 3 millions de lignes, il faut des mois.

Lionel Allorge : Pour l’instant, le noyau Linux, tous ces projets là, il est pas question de les … ?

Basile Starynkevitch : Le noyau Linux pourrait être intéressé par ce genre de chose, en particulier les aspects de règles de codage.

Lionel Allorge : Mais vous pouvez définir, par exemple de ne chercher à optimiser que certaines parties ? C’est modulaire ce que vous faites ?

Basile Starynkevitch : Il y a l’aspect optimisation mais il y a aussi l’aspect "trouver des propriétés statiques et en déduire des warnings contextuels".

Tangui Morlier : En fait peut être qu’au niveau du noyau, y a des mecs de Standford et Standford shaker qui font équipe et qui ont vérifié, il y a Coverity qui font un métier propriétaire,et cetera.

Basile Starynkevitch : Voilà. Ils font tourner

Tangui Morlier : Ils font tourner Coverity sur le noyau, sur des choses comme Apache, Samba, des trucs comme ça, il y a déjà des résultats d’analyse technique.

Basile Starynkevitch : J’ai dépassé mon quota, les autres questions après peut être ?

Tangui Morlier : Merci, merci.

applaudissements