GCC 7 fournira plus de renseignements durant la phase de débogage

GCC 7 fournira plus de renseignements durant la phase de débogage

« Ça marche pas ! »

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

29/08/2016 3 minutes
29

GCC 7 fournira plus de renseignements durant la phase de débogage

Le compilateur GCC 7 sera l’occasion de fournir des messages plus informatifs aux développeurs lors de la phase de débogage. Il s’agit actuellement d’un point faible qui, bien qu’en partie compensé, n’a pas encore été résolu. L’idée est bien sûr d’aider les développeurs pendant la correction des problèmes.

La phase de débogage est une étape délicate dans la conception d’un logiciel ou de n’importe quel produit requérant du code. Quel que soit le langage utilisé, le risque zéro n’existe pas. Un bug est une erreur dans le code, qui peut alors se manifester de plusieurs manières, comme une fonction inopérante, un souci dans l’affichage, voire l’impossibilité de démarrer le logiciel. Il peut ouvrir également une brèche dans la sécurité.

Suggestions et indices de correction

Le débogage consiste donc à repérer les bugs et à les corriger. Il existe de nombreuses manières de les trouver, notamment les retours durant les phases de test, ou des outils intégrés pour éliminer toutes les catégories courantes de problèmes. Les compilateurs peuvent également signaler des soucis pendant qu’ils travaillent. À ce niveau, l’information fournie au développeur est primordiale : plus elle est précise, plus il saura ce qu’il doit faire, ou quel renseignement aller chercher.

GCC 7, actuellement en développement, devrait particulièrement s’améliorer sur ce point. Le renforcement des messages a déjà fait l’objet de plusieurs enrichissements, mais la future version améliorera notamment les suggestions, surtout sur les noms de champs mal écrits. Des indices de correction seront fournis dans un plus grand nombre de cas, dont les erreurs dans les noms de fonctions, les noms des macros, les noms de type, les initialiseurs, ou encore les directives du préprocesseur.

Des améliorations autour de l'assembleur également

Parmi les autres améliorations en préparation, le soulignage de la zone concernée quand un avertissement survient dans une chaine de format. On trouvera également des suggestions de points-virgules manquants, ainsi que pour des arguments ou paramètres mal écrits. Comme l’indique Phoronix, ces apports sont ceux en « l’état » du développement de GCC 7 car il reste encore plusieurs mois de travail avant son arrivée.

GCC 7 sera par ailleurs plus expressif sur l’assembleur, notamment sur sa représentation. Le compilateur fournira des données supplémentaires, comme la signification des expressions mises en avant, et surtout les lignes de code correspondant à la partie de l’assembleur mise en valeur.

Ceux qui souhaitent en savoir davantage pourront consulter les notes de version de GCC 7 (en anglais et en construction).

29

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Suggestions et indices de correction

Des améliorations autour de l'assembleur également

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (29)


“phase de déboggage”, pas sûr que le choix du terme soit heureux pour un compilateur, car lui même opère en phases, j’ai été surpris… Mais bon, des messages utiles, lisibles et informatifs, il serait temps, car clang a quelques années d’avance sur eux à ce niveau, par exemple ..


“division par 0”


Hello, j’ai beau chercher je trouve pas le lien pour soumettre une correction sur l’actu, donc je poste ici…

Je pense qu’il est beaucoup plus juste de traduire “preprocessing directive” par “directives de compilation” (au lieu de “directeurs du préprocesseur”).








TontonBoris a écrit :



Je pense qu’il est beaucoup plus juste de traduire “preprocessing directive” par “directives de compilation” (au lieu de “directeurs du préprocesseur”).





Ou pas, preprocessing n’est pas l’étape de compilation, c’est réalisé par le préprocesseur



Le préprocessing étant la phase avant la compilation (comme son nom l’indique), on dira plutôt :

directives pour le préprocesseur.



Quant à la signalisation des corrections, c’est Signaler une erreur (dans le bandeau du haut, il faut scroller un peu pour le voir).



Edit :







benjarobin a écrit :



Ou pas, preprocessing n’est pas l’étape de compilation, c’est réalisé par le préprocesseur





Ce n’est pas une raison pour garder “les directeurs” <img data-src=" />









fred42 a écrit :



Ce n’est pas une raison pour garder “les directeurs” <img data-src=" />







Les directeurs sentent mauvais, faut les dégager!



Les messages plus informatifs dont il est question sont produites lors de la phase de compilation, pas de débogage… D’ailleurs un compilateur ne fait jamais de débogage.


&gt;&gt;&nbsp;Parmi les autres améliorations en préparation, le soulignage de la zone concernée quand un avertissement survient dans une chaine de format.&nbsp;





&nbsp;J’ai pas bien compris “soulignage” en fait. On parle du compilateur ou de l’IDE ? Sinon, ho wii une option qui remplace automatiquement %s par {0} quand je me trompe de marqueur, à force de sauter d’un langage à l’autre&nbsp;<img data-src=" />








Freud a écrit :



D’ailleurs un compilateur ne fait jamais de débogage.





Ca se discute… Certains compilateurs arrivent à prévoir des dépassements dans du code comme



&nbsp;for (i = 0; i &lt;= n; i++) a[i] = 0;



Est-ce que ça tombe sous le vocable de “debugging” ou pas, telle est la question…



edit : debugging de l’orthographe…



Merci de ne pas me mêler avec ça !

Là, ça devient en public et ça coûte cher !








33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



&nbsp;J’ai pas bien compris “soulignage” en fait. On parle du compilateur ou de l’IDE ?






 &nbsp; On parle bien du compilateur, en fait il fera des messages d'erreur du genre :       






 Erreur : variable var2 non définie :       

code.c:10:&nbsp;&nbsp;&nbsp;&nbsp; resultat = var1 + var2 ;

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

&nbsp;








Uther a écrit :



&nbsp; On parle bien du compilateur, en fait il fera des messages d’erreur du genre :




   Erreur : variable var2 non définie :         

code.c:10:&nbsp;&nbsp;&nbsp;&nbsp; resultat = var1 + var2 ;

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

&nbsp;







Ha ??? Heu ??? Il le faisait pas avant ? Le compilateur Pascal écrit par Wirth et dont je me servais à l’époque mettait une flèche à l’endroit de la ligne où l’erreur était détectée (et il le faisait déjà en 1983) :



code.c:10:&nbsp;&nbsp;&nbsp;&nbsp; resultat = var1 + var2 ;&nbsp;



&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^103

&nbsp;

Oui je sais, le compilateur Pascal n’aurait pas aimé compiler du C… Et les messages d’erreur de l’époque étaient assez spartiates, il fallait savoir que 103 c’était “variable non définie”.

&nbsp;



Personne n’a dit que c’était une grande nouveauté jamais vue ailleurs. &nbsp;Il me semble bien que GCC ne faisait pas ça.








Freud a écrit :



un compilateur ne fait jamais de débogage.





+1



Il ne faudra pas laisser croire que si ça compile, alors ça marche. Le travail est fini !



“Tester, c’est douter”



Si, si il le fait déjà. Mais il va le faire dans plus de cas si j’ai bien compris l’article


m’en fous, chez moi, ça marche !


SI ça compile, 30% du boulot est fait.


Ouais, dans le fond, afficher le code source dans le rapport d’erreurs du compilo ce n’est plus vraiment utile comme à la grande époque. La majorité des développeurs utilise maintenant un editeur capable d’interpréter l’errlog et de se mettre sur la bonne ligne/colonne dans la source…


Pour moi c’est de l’analyse de code, pas du débogage.


Cependant, même si la ligne est indiquer, la partie de la ligne en cause n’est pas forcément indiqué. Par exemple prenons l’exemple donné précédement :

“resultat = var1 + var2 ; ”

Avec l’erreur : “Variable non définie”. l’IDE ne dira pas forcément laquelle des 3 variables n’a pas été définie.

Bon, c’est un exemple simple et bateau, mais j’ai déjà plusieurs fois dû découper une ligne en 4-5 pour savoir où était l’erreur (non sans avoir insulter au préalable Bjarne Stroustrup, maudit mon PC et tout ce qui se toutes les pratique habituelle en ces moments là…).


Oui oui tout à fait, je me suis mal exprimé. Dans l’ancien temps, en cas d’erreur, il “fallait” que le compilateur montre la ligne source et une petite flèche sous le caractère où se trouve l’erreur (comme dans l’exemple) pour bien montrer où est l’erreur, sinon il est difficile de la retrouver dans la source avec les éditeurs de l’époque (non, j’ai pas dit cartes perforées…) surtout si on fait plusieurs modifs.



Actuellement, avec un éditeur “évolué” ou un IDE, le compilateur peut se “contenter” de dire “test.c, ligne 10, colonne 20, variable non définie” et c’est l’éditeur qui se mettra sur la bonne ligne / colonne, en tenant compte si nécessaire des lignes ajoutées/supprimées plus haut dans la source.



Donc oui, le compilo doit donner le nom du fichier, la ligne et la colonne, mais pas nécessairement le code source de cette ligne.

&nbsp;








Freud a écrit :



Pour moi c’est de l’analyse de code, pas du débogage.





Aujourd’hui un debugger exécute le code pour te permettre de voir où les bugs se produisent pour que tu puisses les corriger. C’est une analyse dynamique. Les analyses statiques (qui existent depuis longtemps) permettent le même boulot mais sans exécution de code. Je ne vois pas en quoi cela ne rentre pas dans classe “dégogage”.



La différence est que les analyses dynamiques sont précises (puisque le comportement est celui exact du programme) et incomplète (ne couvrent pas tous les états du programme), alors que les analyses statiques sont (généralement) approximative (sur approximation des états du programme) et complètes (ne laisse pas passer de comportement existant). Les premières n’émettent pas de fausses alarmes, les secondes le peuvent.



Et puis finalement, on peut combiner les deux : analyses statique, détection d’une erreur, production d’un exemple d’exécution fautive. Debugger ou pas debugger ?



Ça dépend du langage, et du compilo derrière.

Ne serait-ce qu’un exemple simple, en C#, le compilo va claquer une erreur si tu essayes d’utiliser une référence sans l’avoir initialisée, alors qu’en C++ le compilo ne va pas broncher; au mieux un warning et encore, je n’en ai pas vu dans Visual C++.


What ? Une référence ne peut pas ne pas être initialisée en C++. Elle peut être invalidée, mais pas non-initialisée.&nbsp; Si c’est une déclaration tu mangeras une erreur, si c’est dans une classe, ça supprime le constructeur par défaut et un constructeur qui ne l’initialise pas sera considéré comme mal-formé et déclenchera une erreur. Un pointeur peut éventuellement être non-initialisé, mais pas une référence.


Désolé, j’avais la flemme d’écrire pointeur, sachant qu’en C++, une référence, techniquement parlant, n’est qu’un pointeur déguisé qui doit être initialisé et ne peut pas être null.

Ça me paraissait évident comme je code toute la journée en C++. <img data-src=" />








Freud a écrit :



D’ailleurs un compilateur ne fait jamais de débogage.





Je ne suis pas totalement d’accord avec toi.

Le debugger est parfaitement inutile en C/C++ si le compilateur n’a pas laissé de traces. Donc oui, le compilateur participe au debug.



Après, je serais ravi d’avoir des messages du genre: “warning: This token will be replaced by a macro”.

Surtout quand c’est le nom de ta classe ou de ta fonction qui se fait shootée par les en-têtes Windows.h

Ex: LoadImage, min, max, …



Je crois que pour avoir un warning sur une variable non initialisé, il faut le mettre en mode paranoïaque avec l’option Wall et Wextra (sinon l’option Wuninitialized ).



Mais en règle général, je trouve que g++/gcc ne sont pas très explicites niveau explication des erreurs et il faut quelques années d’engueulades pour arriver à deviner ce qu’il n’aime pas. Autant avec C, ça va, le langage est très stricte et tout est bien formulé, autant avec C++, c’est une autre paire de manche, plein de truc peuvent se faire sans trop savoir comment, c’est pas forcément claire ce que tu utilises, plein de truc se fait implicitement.








tazvld a écrit :



Autant avec C, ça va, le langage est très stricte et tout est bien formulé






 Euh on doit pas parler du même langage ... Sa norme est un merdier infâme et tout peut te péter dans les mains sans raison. Je bosse dans un labo dont la principale activité est de produire un soft d'analyse de code C et je ne compte même plus le nombre de notion où :      







  • un comportement n’est pas spécifié (sans que ce soit mentionné) et qu’il a fallu en définir une,

  • un comportement est spécifié à plusieurs endroits mais pas avec la même sémantique,

  • et surtout, en nombre démentiels, on a des cas particuliers complètement tordus.*



    * d’ailleurs ce sont souvent eux qui créent le point 2 à cause de chevauchement de définitions où les sémantiques associées sont différentes.

    &nbsp;

    Il y avait un article (autour de CompCert ? je sais plus) qui avait d’ailleurs un peu trollé sur le sujet en disant que vu que de toute façon la norme C est inconsistante, on peut sans problème partir avec faux en hypothèse et faire n’importe quoi derrière, l’implication sera vraie et notre compilateur sera donc correct.



    &nbsp;C++ est à mettre dans le même panier. Il n’est pas plus ou moins bien spécifié que C. Il est juste pareil. C’est la quantité de notions existantes, et le fait que son flot d’exécution soit plus complexe (exceptions, virtualité), qui rendent son analyse plus difficile.