Après avoir vainement cherché un « GDBdebugging considered harmful » j'en suis arrivé à la conclusion qu'il n'existait pas et j'ai donc décidé de l'écrire moi même.
Restons clair, si GDB est un excellent outil pour former les programmeurs débutants à la notion de pointeur et de libération de mémoire, il ne devrait jamais être utilisé pour quoi que ce soit d'autre. Donc passé deux ans à faire du C de façon intensive jetez le aux oubliettes et utilisez des appels intracode pour vous informer des problèmes rencontrés (printf est une bonne solution dans 90% des cas)
Les inconvennients majeurs de GDB :
- Un programme C/C++ compilé en mode "debug" ne se comporte pas (parfois pas du tout) comme le même programme compilé en mode standard. les différences principales sont :
* différence dans le link des bibliothèques. Le simple fait d'activer GDB dans un programme qui lie une bibliothèque compilée sans les options de debug peut faire apparaitre/disparaitre pas mal de bugs.
* différence dans la signature des pointeurs de fonctions. Si vous avez le moindre paramêtre système dans votre fonction, il y a 9 chances sur 10 pour que sa signature change après un passage de GDB. Cela peut également faire apparaitre/disparaitre un paquet de bugs. (des segfault souvent)
* remontée de tout un tas d'appels systèmes pour suivre le déroulement du programme qui n'existent pas dans les versions compilées en standard.
- Dans la plupart des programmes, GDB ne peut pas grand chose pour vous :
* Oubliez le mot clef "volatile" à moins de s'en servir exclusivement pour GDB. (Bon vous allez me dire que de toute façon vous ne connaissiez pas le keyword volatile)
* Oubliez les interruptions systèmes, notamment alarm, gettime et sleep. Certains messages passent, d'autres sont trappés par GDB directemetn sans jamais atteindre votre programme.
* GDB est totalement inutile en cas de programmation concurrente/parallèle. Il ne comprend rien au fichiers mappés en mémoire par un autre process et a du mal avec les messages IPC/ITC (com entre processes, com entre threads) un peu complexe.
* Si pour une raison quelconque, la mémoire allouée par un process est désallouée par un autre, c'est festival.
* Pour les raisons évoquée plus haut n'essayez même pas d'utiliser GDB en dehors du userland, vous allez vous faire mal à le kernel.
- GDB vous empêche de comprendre ce qui se passe vraiment.
* GDB ne comprend pas le code, il le trace. Si vous avez fait une erreur conceptuelle quelque part, GDB vous maintiendra dans l'illusion quand allouant un octet mémoire de plus ou en castant un peu plus violamment une variable ca marche.
* GDB ne comprend pas ce que vous cherchez à faire. A moins de truffer le code de volatile dédiés, GDB va vous aider à debugger les différents cas de figures un par un. A moins d'être très propre, très rigoureux et pas pressé par le temps, votre code (si il est imposant) ressemblera rapidement un un patchwork de verrues et de pansements. On reconnait le code des afficionados de GDB aux nombres de tests qu'il y a dans le code.
* GDB check, trace et valide le code. Il est totalement insensible au système et à l'environnement de la machine. Si votre programme plante suite à un appel système, GDB vous permettra de trouver ou dans le code il faut contourner l'appel système. Mais il ne sera d'aucune utilité sur le pourquoi, le comment et la méthode à adopter pour traiter/ignorer l'appel système.
En bref GDB c'est bien pour les petites applis monotache, mono-utilisateur, monoprocess qui n'ont pas besoin des fonctions systèmes ou d'appels complexes à des bibliothèques extérieures.
# Of GDB considered Harmful
Posté par Jerome Herman . En réponse au journal printf debugging considered harmful. Évalué à 10.
Restons clair, si GDB est un excellent outil pour former les programmeurs débutants à la notion de pointeur et de libération de mémoire, il ne devrait jamais être utilisé pour quoi que ce soit d'autre. Donc passé deux ans à faire du C de façon intensive jetez le aux oubliettes et utilisez des appels intracode pour vous informer des problèmes rencontrés (printf est une bonne solution dans 90% des cas)
Les inconvennients majeurs de GDB :
- Un programme C/C++ compilé en mode "debug" ne se comporte pas (parfois pas du tout) comme le même programme compilé en mode standard. les différences principales sont :
* différence dans le link des bibliothèques. Le simple fait d'activer GDB dans un programme qui lie une bibliothèque compilée sans les options de debug peut faire apparaitre/disparaitre pas mal de bugs.
* différence dans la signature des pointeurs de fonctions. Si vous avez le moindre paramêtre système dans votre fonction, il y a 9 chances sur 10 pour que sa signature change après un passage de GDB. Cela peut également faire apparaitre/disparaitre un paquet de bugs. (des segfault souvent)
* remontée de tout un tas d'appels systèmes pour suivre le déroulement du programme qui n'existent pas dans les versions compilées en standard.
- Dans la plupart des programmes, GDB ne peut pas grand chose pour vous :
* Oubliez le mot clef "volatile" à moins de s'en servir exclusivement pour GDB. (Bon vous allez me dire que de toute façon vous ne connaissiez pas le keyword volatile)
* Oubliez les interruptions systèmes, notamment alarm, gettime et sleep. Certains messages passent, d'autres sont trappés par GDB directemetn sans jamais atteindre votre programme.
* GDB est totalement inutile en cas de programmation concurrente/parallèle. Il ne comprend rien au fichiers mappés en mémoire par un autre process et a du mal avec les messages IPC/ITC (com entre processes, com entre threads) un peu complexe.
* Si pour une raison quelconque, la mémoire allouée par un process est désallouée par un autre, c'est festival.
* Pour les raisons évoquée plus haut n'essayez même pas d'utiliser GDB en dehors du userland, vous allez vous faire mal à le kernel.
- GDB vous empêche de comprendre ce qui se passe vraiment.
* GDB ne comprend pas le code, il le trace. Si vous avez fait une erreur conceptuelle quelque part, GDB vous maintiendra dans l'illusion quand allouant un octet mémoire de plus ou en castant un peu plus violamment une variable ca marche.
* GDB ne comprend pas ce que vous cherchez à faire. A moins de truffer le code de volatile dédiés, GDB va vous aider à debugger les différents cas de figures un par un. A moins d'être très propre, très rigoureux et pas pressé par le temps, votre code (si il est imposant) ressemblera rapidement un un patchwork de verrues et de pansements. On reconnait le code des afficionados de GDB aux nombres de tests qu'il y a dans le code.
* GDB check, trace et valide le code. Il est totalement insensible au système et à l'environnement de la machine. Si votre programme plante suite à un appel système, GDB vous permettra de trouver ou dans le code il faut contourner l'appel système. Mais il ne sera d'aucune utilité sur le pourquoi, le comment et la méthode à adopter pour traiter/ignorer l'appel système.
En bref GDB c'est bien pour les petites applis monotache, mono-utilisateur, monoprocess qui n'ont pas besoin des fonctions systèmes ou d'appels complexes à des bibliothèques extérieures.
Pour le reste, utilisez votre cerveau.