Volatiles Are Miscompiled, and What to Do about It

Je vous conseille la lecture d’un excellent article rédigé par deux chercheurs de l’Université de l’Utah, à Salt Lake City, USA :  Volatiles Are Miscompiled, and What to Do about It. Eric Eide et John Regehr se sont rendus compte lors de leurs travaux que leur compilateur générait un code assembleur incorrect à partir d’un code en C contenant le mot-clé volatile. Ils ont alors évalué 13 compilateurs pour vérifier leur comportement en présence de ce mot faisant penser à un oiseau et ont constaté que tous y perdaient des plumes, générant des codes assembleurs qui ne faisaient pas du tout ce que les codes C demandaient ! L’article retrace leurs observations, décrit leurs méthodes de tests et propose des solutions pour éviter ou contourner ces mauvaises compilations.

ABSTRACT
C’s volatile qualifier is intended to provide a reliable link between
operations at the source-code level and operations at the memorysystem
level. We tested thirteen production-quality C compilers
and, for each, found situations in which the compiler generated
incorrect code for accessing volatile variables. This result is disturbing
because it implies that embedded software and operating
systems—both typically coded in C, both being bases for many
mission-critical and safety-critical applications, and both relying
on the correct translation of volatiles—may be being miscompiled.
Our contribution is centered on a novel technique for finding
volatile bugs and a novel technique for working around them. First,
we present access summary testing: an efficient, practical, and automatic
way to detect code-generation errors related to the volatile
qualifier. We have found a number of compiler bugs by performing
access summary testing on randomly generated C programs. Some
of these bugs have been confirmed and fixed by compiler developers.
Second, we present and evaluate a workaround for the compiler
defects we discovered. In 96% of the cases in which one of
our randomly generated programs is miscompiled, we can cause the
faulty C compiler to produce correctly behaving code by applying
a straightforward source-level transformation to the test program.

Au cas où l’abstract ne vous aurait pas suffit, voici un exemple tiré de l’introduction de l’article qui vous mettra l’eau à la bouche et vous fera lire l’article !

/* linker will map to the proper I/O register */
extern volatile int WATCHDOG;
void reset_watchdog()
{
    WATCHDOG = WATCHDOG; /* load, then store */
}

Compilé avec GCC pour IA32 :

reset_watchdog:
    movl WATCHDOG, %eax
    movl %eax, WATCHDOG
    ret

Compilé avec GCC pour MSP430 :

reset_watchdog:
    ret

Oui, il y a un os avec ce chien de garde !

Bonne lecture !

 

 

 

Publicités

2 Réponses

  1. C’est marrant, j’ai également lu cet article il y a quelques jours. Par contre, il date ici, voir ici pour savoir ce qu’il s’est passé depuis.

    J'aime

    4 juillet 2012 à 2:01

    • Salut !

      Intéressant ton lien. Au final, son constat est presque plus accablant qu’il y a quelques années. Certes, certains compilateurs ont progressé, certes il existe CompCert pour vérifier les résultats des compilateurs, mais les volatiles mettent toujours le bazar et il faut mieux utiliser des fonctions d’accès à des variables bien protégées).

      Ca me rappelle une technique pour la gestion de variables globales. Voir la fin du premier commentaire ici.

      J'aime

      9 juillet 2012 à 11:16

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s