Blog Haypo

Aller au contenu | Aller au menu | Aller à la recherche

lundi 15 octobre 2007

Linus corrige un bug dans gcc

J'avais déjà lu que le noyau Linux est un bon test pour une version de gcc. J'en ai maintenant la preuve avec une nouvelle démonstration de Linus Torvald. L'histoire commence avec un courriel du développeur noyau suractif Ingo Molnar le 2 octobre vers minuit. Six heures plus tard, Linus répond que c'est un bogue du compilateur gcc.

Il montre que le code en langage machine cité dans le Oops noyau recopié dans le courriel d'Ingo ne correspond pas au code source C du noyau :

Code: 89 45 f0 76 77 eb 7a 8b 55 ec 8b 4d ec 
89 f7 8b 02 89 c2 03 51 0c 29 c7 89 f0 89 79 
0c 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 
<8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 8b 45 
08 0f be d9 89 da e8

Il écrit :

Lookie here:
- the bug happens on this:
       char c = *p++;
- which has been compiled into
       8b 3a           mov    (%edx),%e
which is a *word* access.

Quarante minutes plus tard, Ingo répond qu'il demeure perplexe « hm, it's 4.0.2. Not the latest & greatest but i've been using it for 2 years and this would be the first time it miscompiles a 32-bit kernel out of tens of thousands of successful kernel bootups. ». Mais les échanges suivants avec d'autres interlocuteurs réussissent à persuader Ingo.

Je pense que le bogue gcc 4.0.2 a été rapporté mais je n'en ai pas trouvé les traces. C'est quand même un bel exploit de l'expertise Linus qui semble habitué aux bogues du compilateur.

mardi 2 octobre 2007

PHP, outil de torture pour développeur

Je travaille actuellement sur le projet Nuface pour INL. Environ cinq personnes travaillent ou ont travaillé sur ce projet écrit en PHP (3/4) et Python (1/4). Le qualité du code source laisse à désirer. Je fais de mon mieux pour simplifier le code tout en le rendant plus simple à comprendre, mais c'est une tâche difficile et pénible. J'ai alors cherché des outils pour m'aider dans ma tâche.

Analyse statique de code

J'ai cherché des outils d'analyse statique de code pour PHP. Malheureusement, je n'en ai trouvé que quatre : Pixy, SWAAT, php-sat et PHP String Analyzer (phpsa). Les deux premiers sont dédiés à la sécurité, ce qui ne m'intéresse pas (injection SQL et XSS). phpsa est un drôle de projet dont je n'ai pas compris l'intérêt, et j'ai donc finalement testé php-sat. L'installation est longue car il n'existe aucun paquet Ubuntu Feisty, ni pour php-sat, ni pour les nombreuses dépendances. Ordre dans lequel il faut les installer (de mémoire) :

  • aterm (2.5)
  • sdf2 (2.4)
  • strategoxt (0.17)
  • php-front (0.1pre401)
  • php-sat (0.1pre344)

Une fois que j'ai terminé de tout compiler et installer, j'obtiens ce joli message :

$ php-sat -i index.php
[ php-sat | error ] invalid box:
        KnownString{SafetyLevel([KnownString])}

Je ne comprend rien à ce message d'erreur cryptique que j'obtiens qu'importe le fichier passé en argument. Ayant passé deux heures à tout installer, je suis plutôt déçu et décide d'abandonner. La bonne pratique serait de contacter Eric Bouwers, l'auteur de php-sat pour lui rapporter mon problème, mais je ne l'ai pas (encore) fait.

Note : L'outil SWAAT a l'air d'être un bon outil pour trouver rapidement des failles de sécurité dans vos applications.

Eclipse et PDT

Un ami — feth — m'a montré les fonctions de refactoring de l'environnement de développement Eclipse. Bluffé par la facilité de renommer une variable ou créer une sous-fonction, je me suis décidé à l'installer pour pouvoir l'utiliser sur du code PHP. Une petite recherche m'a guidé vers PHPEclipse et PDT. Le premier n'est plus développé en faveur du second qui est sponsorisé par Zend, entreprise à l'origine du langage PHP. Zend emploie Yossi Leon pour travailler sur ce projet à plein temps.

J'ai d'abord installé Eclipse via Ubuntu : c'est la version 3.2 qui est disponible. Or quand j'ai voulu ajouter le greffon PDT, j'apprend qu'il faut la version 3.3 d'Eclipse. D'ailleurs, je réalise au passage que PDT est sorti en version 1.0 le 18 septembre dernier, c'est donc tout frais !

J'ai alors installé Eclipse en téléchargeant Eclipse Classic (eclipse-SDK-3.3.1-linux-gtk.tar.gz). Pour importer le projet Nuface, j'ai d'abord installé Subclipse, le greffon Subversion.

Finalement, tout s'est bien emboîté : Nuface s'ouvre à merveille dans Eclipse additionné de Subclipse et PDT. Eclipse affiche directement des avertissements sur la documentation écrite en docbook (format basé sur XML). En corrigeant l'erreur sur le charset incorrect, il arrive ensuite à détecter les erreurs de DTD (docbook). Chapeau !

Enfin, quand je cherche la fonction de refactoring « créer une sous-fonctions » — après deux heures d'installation — je découvre que la fonction n'existe tout simplement pas ! Seule la fonction pour renommer une variable ou une fonction est disponible dans PDT 1.0. Or j'avais installé Eclipse uniquement pour cette fonction... grosse déception.

Plantage PHP

Pour finir en beauté, aujourd'hui j'ai trouvé un bug critique dans l'interpréteur PHP. J'ai mis trois heures à isoler un bug ridicule qui fait planter le processus Apache (child pid 12946 exit signal Segmentation fault (11)). Les détails du plantage sont disponibles dans mon rapport de bug (#42817). Je pense que vu la popularité de PHP, ce bug peut être une faille de sécurité.

PHP est à vomir

Étant un programmeur de longue date, je suis très déçu de PHP. Langage crée en 1994, sa dernière version majeure (PHP5) élimine quelques défauts du modèle objet et comble certaines lacunes (ex: gestion des exceptions). Mais PHP 5.2 ne supporte pas Unicode et est vraiment trop laxiste selon moi. En particulier, accéder à une variable indéfinie ou à une clé inexistante d'un tableau devrait être proscrit. Pour que la programmation en PHP soit supportable, il faut travailler dans un niveau d'avertissement maximum : « error_reporint(E_ALL); ». Je vous conseille de jetter un Å“il au fichier debug.php de Nuface, il contient en particulier un gestionnaire d'erreur écrit PHP (nuface_error_handler).

Bon, moi je vais retourner coder des tests unitaires pour SimpleTest... Pour information, la version CVS offre une méthode expectException(), nécessaire pour pouvoir tester les exceptions.

Compilateurs C libres

Suite à l'annonce de l'intégration de PCC dans NetBSD, je me suis intéressé aux compilateurs libres qui existent. En chatouillant Google et Wikipédia, j'ai obtenu cette petite liste :

  • GCC (GNU Compiler Collection)
    • Licence GNU GPLv2 avec un poil de LGPL
    • Projet lancé en 1985 par Richard Stallman et développé aujourd'hui en partie par RedHat. Fait parti du projet GNU.
    • Intégré dans de nombreux IDE. Exemples : DJGPP (MS-DOS) ; MinGW, Cygwin et Dev-C++ (Windows) ; etc.
  • PCC (Portable C Compiler)
    • Licence BSD
    • Projet lancé dans la fin des années 1970 par Stephen C. Johnson
    • Plus d'informations dans les commentaires de l'annonce linuxfr et des critiques de gcc
  • Watcom
    • Logiciel libéré en 2003 : OpenWatcom (licence)
    • Logiciel propriétaire ayant pour origine un compilateur Fortran écrit en 1965 par des étudiants de l'Université de Waterloo (Canada). Une version optimisée pour le C et pour PC est apparue en 1988 (Watcom C 6.0). Lire l'histoire complète.
    • Compilateurs de tous les jeux MS-Dos de 1993 à 1996 (DOOM, Descent et Duke Nukem 3D, etc.)
  • LLC (Local C Compiler)
    • Développé par Chris Fraser et David Hanson
    • Projet de l'Université de Princeton
    • Logiciel libre ?
    • Intégré dans l'IDE « Lcc-win32 »
  • SDCC (Small Device C Compiler)
    • Licence GNU GPL
    • Projet lancé Sandeep Dutta et ouvert aux contributions (Sourceforge) en 1999
  • TCC (Tiny C Compiler)
  • TenDRA
    • Projet initié par la DERA (agence du département de la Défense du Royaume-Uni) au milieu des années 1990
    • Licence BSD

Cette liste est sûrement incomplète, mais je pense que les compilateurs libres les plus populaires y sont listés. Consultez également la liste des compilateurs C de Wikipédia anglophone. Il existe de nombreux compilateurs commerciaux dont certains sont gratuits sous certaines conditions : Microsoft (Visual Studio), Intel (ICC), Borland (Turbo C, C++ Builder), ...

Pour information, un programme C exécuté dans LLVM 2.0 (Low Level Virtual Machine) est 20% plus rapide que lorsqu'il est exécuté avec GCC 4.2. On peut donc supposer que LLVM a accès à des algorithmes d'optimisation auxquels GCC n'a pas accès (sûrement parce que GCC est statique alors que LLVM est dynamique).

Pour les plus passionnés, un lien utile : Linux Assembly.

Perso, je suis déçu que PyPy n'ai pas réussi à être plus rapide que CPython (l'implémentation de référence en C) car pourtant sa technologie était bien plus évoluée :-( Apparemment, PyPy est plus un laboratoire d'expérimentation qu'une implémentation optimisée de Python.