L’expression GDB ou repos revient régulièrement dans les échanges entre développeurs embarqués, administrateurs systèmes et ingénieurs logiciels. Derrière cette formulation se cache un choix technique récurrent : lancer une session de débogage avec le GNU Debugger ou laisser le processus en état de repos pour analyser un dump post-mortem. Les deux approches ne répondent pas aux mêmes contraintes, et les confondre mène à des pertes de temps considérables.
GDB en mode actif ou analyse post-mortem : deux philosophies de débogage
Le débogueur GNU permet deux usages fondamentalement différents. Le premier consiste à attacher GDB à un processus en cours d’exécution, poser des breakpoints, inspecter la pile d’appels et modifier des variables à la volée. Le second repose sur l’analyse d’un core dump, fichier généré quand un programme se termine de façon anormale.
Lire également : Nouvelles technologies et environnement : impact et solutions à connaître
Nous observons que la confusion entre ces deux modes est à l’origine de la plupart des erreurs de méthodologie. Déboguer en temps réel un programme qui plante de manière non déterministe revient souvent à chercher une aiguille dans une botte de foin. L’analyse post-mortem (le « repos » du processus, si l’on veut) offre alors un instantané exploitable sans perturber le comportement du programme.
Le choix entre GDB actif et core dump dépend de la reproductibilité du bug. Un segfault systématique à la même ligne se débogue en live. Un plantage aléatoire sous charge nécessite un core dump analysé à froid.
A voir aussi : Les dernières mises à jour de French Stream
Compiler avec les symboles de débogage
Quel que soit le mode choisi, la compilation avec l’option -g de gcc reste un prérequis. Cette option intègre dans l’exécutable les informations sur les noms de variables et le code source. Sans elle, GDB ne peut afficher que des adresses mémoire brutes, rendant l’analyse quasi impossible.
GDB ou repos sur cible embarquée : contraintes spécifiques
Sur un système embarqué, la question « GDB ou repos » prend une dimension supplémentaire. Le débogage ne se fait plus sur la machine locale mais à distance, via gdbserver installé sur la cible. La latence réseau, les accès mémoire restreints et les contraintes temps réel changent radicalement la donne.
Attacher GDB à un processus sur une carte embarquée interrompt l’exécution du firmware. Pour des systèmes temps réel, cette interruption peut déclencher des watchdogs, provoquer des timeouts sur des bus de communication ou fausser complètement le comportement observé. Nous recommandons dans ce cas de privilégier le mode « repos » : laisser le système fonctionner, collecter des traces ou provoquer un core dump contrôlé, puis analyser hors ligne.
- GDB distant via gdbserver convient aux phases de développement précoce, quand le firmware n’a pas encore de contraintes temps réel strictes
- L’analyse post-mortem s’impose dès que le système pilote du matériel sensible aux interruptions (moteurs, capteurs analogiques, protocoles de communication synchrones)
- Les traces de type printf ou syslog restent un complément utile quand ni GDB actif ni le core dump ne suffisent à identifier un race condition
Erreurs fréquentes avec GDB : signification des messages courants
La signification des messages d’erreur de GDB déroute souvent les développeurs qui ne maîtrisent pas la chaîne de compilation. Voici les cas que nous rencontrons le plus souvent.
No debugging symbols found
Ce message apparaît quand l’exécutable a été compilé sans l’option -g. GDB fonctionne, mais ne peut pas associer les adresses mémoire à du code source lisible. La solution consiste à recompiler avec gcc -g -Wall et relancer la session.
Program received signal SIGSEGV
Le signal SIGSEGV indique un accès mémoire invalide. GDB arrête l’exécution à l’endroit du plantage. La commande bt (backtrace) affiche alors la pile d’appels complète. L’erreur fréquente ici est de relancer le programme sans analyser la backtrace, perdant ainsi l’information la plus précieuse.
Cannot access memory at address
Ce message survient quand on tente d’inspecter une zone mémoire non mappée. Sur un système embarqué avec gdbserver, il peut aussi indiquer un problème de configuration des plages mémoire accessibles à distance. Vérifier le fichier de configuration mémoire de la cible avant de soupçonner un bug dans le code.
GDB face aux alternatives modernes : quand le repos devient un choix d’architecture
L’intégration de GDB dans les IDE modernes (CLion, VS Code avec l’extension C/C++) a simplifié l’interface, mais n’a pas changé le moteur sous-jacent. GDB reste le débogueur de référence pour les projets C et C++ sous Linux. LLDB, son équivalent dans l’écosystème LLVM, le remplace sur macOS depuis plusieurs années.
Le vrai changement de paradigme vient de l’observabilité. Sur des systèmes distribués ou des firmwares complexes, le débogage en temps réel cède du terrain aux outils de tracing (ftrace, perf, eBPF). Ces outils fonctionnent en mode « repos » du point de vue du développeur : le système tourne normalement, les données sont collectées en arrière-plan, l’analyse se fait ensuite.
Ce glissement n’invalide pas GDB. Il redéfinit son périmètre. GDB excelle pour les bugs déterministes, les crashes reproductibles, l’inspection fine d’un algorithme. Pour les problèmes de performance, les fuites mémoire lentes ou les race conditions, les outils d’observabilité prennent le relais.
- GDB actif : bugs déterministes, segfaults reproductibles, inspection pas-à-pas d’un algorithme
- Core dump + GDB : plantages non reproductibles, analyse post-mortem sur cible embarquée
- Outils de tracing : problèmes de performance, comportements intermittents sous charge, fuites mémoire progressives
- Combinaison des trois : approche réaliste sur un projet de taille moyenne à grande
La question « GDB ou repos » n’appelle pas une réponse unique. Elle dépend du type de bug, de l’environnement d’exécution et de la maturité du projet. Un développeur qui maîtrise les deux modes, et sait quand basculer de l’un à l’autre, gagne un temps considérable sur chaque session de débogage.
