Un objet partagé a été construit sur Linux RedHat et alors que tout le code était compilé avec debug, le débogueur (gdb) a refusé de charger les symboles et a émis une erreur comme dans:
...
GNU gdb Fedora (6.8-37.el5)
...
This GDB was configured as "x86_64-redhat-linux-gnu"...
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module libgrokf.so]
Avec cette erreur, je ne pouvais obtenir le déclenchement de points d'arrêt dans aucune fonction ni voir la trace de pile appropriée. J'ai recompilé l'ensemble du projet mais rien n'y fait. Je sais qu’il n’ya pas eu de problème de débogage de ce module par le passé.
Qu'est-ce qui cause ce problème?
Le problème est que votre version de gdb
ne prend pas en charge la version DWARF
utilisée dans l’un de vos fichiers binaires.
La solution: mettez à jour gdb
ou compilez vos fichiers en utilisant un autre format de débogage (DWARF2
fonctionne avec gdb
6).
J'ai récemment eu ce problème avec freeBSD
et nasm
, nasm
en compilant les fichiers binaires avec DWARF3
et la gdb
fournie avec freeBSD 9.1
ne l'accepte pas.
J'espère que cette réponse aidera toute personne ayant un problème similaire: P
En l'occurrence, le module qui n'a pas pu déboguer a été principalement construit à partir de sources, à l'exception d'un petit fichier objet 'externe', someextcode.o, fourni par une tierce partie.
En examinant le problème, il a été constaté que le fichier someextcode.c avait été compilé avec l'indicateur -g3 qui, apparemment, place la version DWARF de 4 dans l'en-tête de l'unité de compilation. Changer cela en -g a résolu le problème.
Malheureusement, il semble qu'un problème avec un seul module puisse compromettre la capacité de débogage d'un objet partagé entier (.so) sans donner une indication claire de l'origine du problème.
Mon problème a été résolu en choisissant la bonne version de gdb pour le débogage. Auparavant, j'utilisais gdb 7.0 ... et lorsque j'ai commencé à utiliser la version 7.10 de gdb, j'ai pu déboguer mon application.