Réponses:
Si vous utilisez Linux, utilisez objdump --debugging
. Il doit y avoir une entrée pour chaque fichier objet dans la bibliothèque. Pour les fichiers objets sans symboles de débogage, vous verrez quelque chose comme:
objdump --debugging libvoidincr.a
In archive libvoidincr.a:
voidincr.o: file format elf64-x86-64
S'il y a des symboles de débogage, la sortie sera beaucoup plus détaillée.
objdump -g
ne me donne rien pour un simple test.o compilé avec et sans g
, ce qui le rend effectivement inutile. Ubuntu 12.04, gcc 4.6.3, objdump GNU 2.22. nm -a
semble être plus utile.
La commande suggérée
objdump --debugging libinspected.a
objdump --debugging libinspected.so
me donne toujours le même résultat au moins sur Ubuntu / Linaro 4.5.2:
libinspected.a: file format elf64-x86-64
libinspected.so: file format elf64-x86-64
peu importe si l'archive / la bibliothèque partagée a été construite avec ou sans -g
option
Ce qui m'a vraiment aidé à déterminer si a -g
été utilisé est l' outil Readelf :
readelf --debug-dump=decodedline libinspected.so
ou
readelf --debug-dump=line libinspected.so
Cela imprimera un ensemble de lignes comprenant le nom du fichier source, le numéro de ligne et l'adresse si de telles informations de débogage sont incluses dans la bibliothèque , sinon cela n'imprimera rien .
Vous pouvez passer la valeur que vous jugerez nécessaire pour l' --debug-dump
option au lieu de decodedline
.
Ce qui a aidé est:
gdb mylib.so
Il s'imprime lorsque les symboles de débogage ne sont pas trouvés:
Reading symbols from mylib.so...(no debugging symbols found)...done.
Ou une fois trouvé:
Reading symbols from mylib.so...done.
Aucune des réponses précédentes ne donnait de résultats significatifs pour moi: les bibliothèques sans symboles de débogage donnaient beaucoup de résultats, etc.
nm -a <lib>
affichera tous les symboles de la bibliothèque, y compris ceux de débogage.
Vous pouvez donc comparer les sorties de nm <lib>
et nm -a <lib>
- si elles diffèrent, votre bibliothèque contient des symboles de débogage.
nm -a
a un alias nm --debug-syms
qui est explicite :-).
diff <(nm <lib>) <(nm -a <lib>)
pour obtenir une différence facile
Sur OSX, vous pouvez utiliser dsymutil -s
et dwarfdump
.
En utilisant, dsymutil -s <lib_file> | more
vous verrez les chemins des fichiers source dans les fichiers qui ont des symboles de débogage, mais uniquement les noms de fonction sinon.
dsymutil -s
? L'existence de la sortie signifie-t-elle qu'elle a été construite avec des symboles de débogage, ou doit-elle être greffée?
Réponses suggérant l'utilisation objdump --debugging
ou readelf --debug-dump=...
ne fonctionnant pas dans le cas où les informations de débogage sont stockées dans un fichier séparé du binaire, c'est-à-dire que le binaire contient une section de lien de débogage . On pourrait peut-être appeler cela un bug readelf
.
Le code suivant doit gérer cela correctement:
# Test whether debug information is available for a given binary
has_debug_info() {
readelf -S "$1" | grep -q " \(.debug_info\)\|\(.gnu_debuglink\) "
}
Voir Fichiers de débogage séparés dans le manuel GDB pour plus d'informations.
obdjump -W lib
etreadelf -w lib
. Ce dernier est plus configurable - voir la page de manuel readelf (1).