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

« Ça marche pas ! »

Le 29 août 2016 à 13h00

3 min

Logiciel

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).

Commentaires (29)

jmm

Le 29/08/2016 à 17h16

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”

benjarobin Abonné

Le 29/08/2016 à 18h07

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

anagrys Abonné

Le 29/08/2016 à 18h59

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

tazvld Abonné

Le 29/08/2016 à 19h06

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

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 29/08/2016 à 19h38

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…

Freud

Le 29/08/2016 à 19h58

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

tazvld Abonné

Le 29/08/2016 à 20h38

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à…).

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 30/08/2016 à 05h46

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.

 

Ksass`Peuk

Le 30/08/2016 à 07h06

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 ?

sephirostoy Abonné

Le 30/08/2016 à 07h33

Ç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++.

Ksass`Peuk

Le 30/08/2016 à 07h51

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.  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.

sephirostoy Abonné

Le 30/08/2016 à 09h43

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++. " />

Altair31

Le 30/08/2016 à 13h31

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, …

tazvld Abonné

Le 30/08/2016 à 14h04

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.

Ksass`Peuk

Le 31/08/2016 à 06h52

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.

 

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.

 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.

Iste

Le 29/08/2016 à 13h23

Tim-timmy

Le 29/08/2016 à 13h32

“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 ..

Northernlights

Le 29/08/2016 à 13h55

“division par 0”

TontonBoris Abonné

Le 29/08/2016 à 14h06

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”).

benjarobin Abonné

Le 29/08/2016 à 14h11

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

fred42 Abonné

Le 29/08/2016 à 14h13

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” " />

CryoGen

Le 29/08/2016 à 14h21

fred42 a écrit :

Ce n’est pas une raison pour garder “les directeurs” " />

Les directeurs sentent mauvais, faut les dégager!

Freud

Le 29/08/2016 à 14h49

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.

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 29/08/2016 à 14h53

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

 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 " />

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 29/08/2016 à 14h57

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

 for (i = 0; i <= 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…

fred42 Abonné

Le 29/08/2016 à 15h03

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

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

Uther Abonné

Le 29/08/2016 à 15h25

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

 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;

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 29/08/2016 à 15h45

Uther a écrit :

  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:     resultat = var1 + var2 ; 

                                                          ^103

 

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”.

 

Uther Abonné

Le 29/08/2016 à 16h41

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