gdb, acronyme de GNU DeBugger, est un programme qui, comme son nom l'indique, permet de débugger un programme (langages C et C++ principalement, ainsi que d'autres : fortran 77, etc..). Il permet donc de traquer les bugs/erreurs se trouvant dans tout programme.
Cet outil, indispensable à tout programmeur, bien que très performant n'est disponible qu'avec une interface en ligne de commande. Heureusement, il existe des interfaces graphiques qui facilitent le débuggage.
Installez les paquets build-essential,gdb
Si vous développez en utilisant une bibliothèque particulière, vous pouvez éventuellement installer le paquet de débuggage, dont le nom finit par -dbg, en plus du paquet de développement (dont le nom finit par -dev).
Pour que gdb puisse débugger un programme, il a besoin des informations de débuggage, qui peuvent être ajoutées en ajoutant l'option -g au compilateur.
Exemple :
gcc -g toto.c -o toto
Un fois le programme compilé, invoquez gdb comme ceci :
gdb toto
gdb -tui toto
qui permet de visualiser le code, les points d'arrêt… bref plus visuel… mais semble buggé
Dans l'interface de gdb, vous pouvez lancer le programme avec run et quitter le débogueur avec quit. À tout moment, vous pouvez interrompre le programme avec le raccourci clavier Ctrl+C dans le terminal. La commande where vous permettra alors de voir la pile des appels. Pour reprendre l'exécution du programme, tapez continue.
Si vous souhaitez changer l'exécutable ciblé par gdb, exec monexecutable peut vous être utile.
La commande start lance le programme et s'arrête à la première ligne : la commande "n" permet ensuite de faire du pas-à-pas.
| commande | raccourci | effet |
|---|---|---|
| run | r | lance le programme (s'arrête au prochain point d'arrêt) |
| continue | c | relance le programme (s'arrête au prochain point d'arrêt) |
| ~~~ | ~~~ | ~~~ |
| break [yyy.c:]xx | b [yyy.c:]xx | place un point d'arrêt à la ligne xx du fichier yyy.c (si indiqué) |
| info breakpoints | info breakpoints | liste les points d'arrêts |
| delete [x] | d [x] | efface les points d'arrêts si pas d'argument, ou le point d'arrêt correspondant au n° x |
| ~~~ | ~~~ | ~~~ |
| next | n | exécute une instruction (ne rentre pas dans les fonctions) peut-être suivi du nombre de ligne à exécuter |
| step | s | exécute une instruction (rentre potentiellement dans les fonctions) |
| finish | f | exécute les instructions jusqu'à la sortie de la fonction |
| list | l | affiche 10 lignes de code centrée sur la ligne à exécuter |
| until xx | u xx | |
| monitor reset halt |
Si vous soupçonnez une fonction particulière de faire bugger votre programme, vous pouvez placer un breakpoint (point d'arrêt) avant le lancement de cette fonction. Pour ce faire, utilisez la commande break mafonction (sans les parenthèses).
Si la fonction désirée est située dans une classe ou un namespace (espace de noms) niveau_englobant, elle est accessible depuis niveau_englobant::mafonction.
Pour afficher la liste des points d'arrêt, utilisez info breakpoints. Vous remarquerez que chaque point d'arrêt est identifié par un numéro :
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x08049850 in thor::GameApp::catchEvents()
at src/gameapp.cpp:104
Ici, il a pour identifiant 1. S'il ne vous intéresse plus, vous pouvez le supprimer avec la commande delete 1.
break xx
Pour aller au prochain point d'arrêt, écrire continue.
Il est possible d'afficher la valeur d'une variable une fois que le programme a été interrompu, grâce à la commande
print ma_variable
ou encore, en abbrégé et en spécifiant un type (x:hexa, d:decimal, f:float, c:char, s:string… help x pour les voir tous):
p/f ma_variable_reelle
La même remarque (§ précédent) sur la portée, concernant les classes et les espaces de nom s'applique ici.
et pour une variable qui est un tableau de char de 16 caractères:
p/c ma_char_chaine@16
Il existe de multiples interfaces graphiques pour gdb qui facilitent grandement le débuggage en affichant le code source, créant des schémas représentant les variables, etc. En voici quelques-unes :
Aussi, quelques environnements de développement incluent une interface graphique pour gdb ; c'est le cas d'Anjuta, d'Eclipse ou encore de KDevelop.
Enfin signalons le concurrent idb (d'intel, non libre) qui a un mode "gdb" (même syntaxe) et qui affiche correctement les tableaux, ce qui n'est pas le cas de gdb pour le fortran. Il s'installe en même temps que le compilateur ifort.