Wie kann ich feststellen, ob eine Bibliothek mit -g kompiliert wurde?

Lesezeit: 4 Minuten

Benutzeravatar von Dan Hook
Dan Haken

Ich habe einige kompilierte Bibliotheken unter x86-Linux und möchte schnell feststellen, ob sie mit Debugging-Symbolen kompiliert wurden.

Der vorgeschlagene Befehl

objdump --debugging libinspected.a
objdump --debugging libinspected.so

gibt mir immer das gleiche Ergebnis zumindest auf Ubuntu/Linaro 4.5.2:

libinspected.a:     file format elf64-x86-64
libinspected.so:     file format elf64-x86-64

egal ob das Archiv/die Shared Library mit oder ohne gebaut wurde -g Möglichkeit

Was mir wirklich geholfen hat, festzustellen, ob -g verwendet wurde ist gelesen Werkzeug:

readelf --debug-dump=decodedline libinspected.so

oder

readelf --debug-dump=line libinspected.so

Dadurch wird eine Reihe von Zeilen gedruckt, die aus dem Quelldateinamen, der Zeilennummer und der Adresse bestehen wenn solche Debug-Informationen in der Bibliothek enthalten sindsonst wird es gedruckt nichts.

Sie können jeden Wert übergeben, den Sie für notwendig halten --debug-dump Option statt decodedline.

  • funktioniert perfekt. Ich habe diesen Befehl auf meiner ausführbaren Datei mit dem ersten CMAKE_BUILD_TYPE RELEASE ausprobiert und der Befehl wurde leer zurückgegeben. Dann habe ich es mit CMAKE_BUILD_TYPE DEBUG versucht und dann gab es ziemlich viele Ausgaben.

    – Informationen verstopft

    22. August 2017 um 15:56 Uhr

Benutzeravatar von Matt McClellan
Matt McClellan

Wenn Sie Linux verwenden, verwenden Sie objdump --debugging. Es sollte einen Eintrag für jede Objektdatei in der Bibliothek geben. Bei Objektdateien ohne Debugging-Symbole sehen Sie etwa Folgendes:

objdump --debugging libvoidincr.a
In archive libvoidincr.a:

voidincr.o:     file format elf64-x86-64

Wenn Debugging-Symbole vorhanden sind, ist die Ausgabe viel ausführlicher.

  • Es gibt auch obdjump -W lib und readelf -w lib. Letzteres ist besser konfigurierbar – siehe readelf(1) Manpage.

    – przemoc

    4. Januar 2010 um 14:16 Uhr

  • Für jede Binärdatei (einschließlich der mit -g kompilierten) gibt mir objdump die Antwort “keine erkannten Debugging-Informationen”, es sei denn, ich kompiliere sie mit -gstabs. Dies scheint ein erkannter Fehler zu sein.

    – Dan Hook

    4. Januar 2010 um 14:24 Uhr

  • Dan, auf welcher Plattform hast du das versucht?

    – schw

    4. Januar 2010 um 14:38 Uhr

  • Angewandtes Russisch: von man objdump(1), das Flag –debugging “versucht, die in der Datei gespeicherten STABS- und IEEE-Debugging-Formatinformationen zu parsen und sie mit einer C-ähnlichen Syntax auszudrucken. Wenn keines dieser Formate gefunden wird, fällt diese Option zurück mit der Option -W, um alle DWARF-Informationen in der Datei zu drucken.”

    – Matt McClellan

    5. Januar 2010 um 17:13 Uhr

  • objdump -g gibt mir nichts für ein einfaches test.o, das sowohl mit als auch ohne kompiliert wurde g, wodurch es effektiv nutzlos wird. Ubuntu 12.04, gcc 4.6.3, GNU-Objdump 2.22. nm -a scheint sinnvoller zu sein.

    – jw013

    20. September 2013 um 13:49 Uhr

Was geholfen hat ist:

gdb mylib.so

Es wird gedruckt, wenn keine Debug-Symbole gefunden werden:

Reading symbols from mylib.so...(no debugging symbols found)...done.

Oder wenn gefunden:

Reading symbols from mylib.so...done.

Keine der früheren Antworten lieferte aussagekräftige Ergebnisse für mich: Bibliotheken ohne Debug-Symbole lieferten viel Ausgabe usw.

  • Danke! Das hat bei mir funktioniert, indem ich den Clang-Compiler in Android mit cmake verwendet habe 🙂

    – Pär Nils Amsen

    26. Mai 2017 um 10:56 Uhr

  • Super toll für einen schnellen Check! funktioniert auch mit *.o-Objektdateien.

    – Stéphane Rolland

    13. Juni 2020 um 18:58 Uhr


nm -a <lib> druckt alle Symbole aus der Bibliothek, einschließlich Debug-Symbole.

So können Sie die Ausgaben von vergleichen nm <lib> und nm -a <lib> – Wenn sie sich unterscheiden, enthält Ihre Bibliothek einige Debug-Symbole.

Benutzeravatar von glennr
Glennr

Unter OSX können Sie verwenden dsymutil -s und dwarfdump.

Verwenden dsymutil -s <lib_file> | more Sie werden Quelldateipfade in Dateien mit Debug-Symbolen sehen, ansonsten aber nur die Funktionsnamen.

  • Können Sie näher erläutern, wonach Sie in der Ausgabe von z. B. dsymutil -s? Bedeutet das Vorhandensein einer Ausgabe, dass sie mit Debug-Symbolen erstellt wurde, oder sollte sie gruppiert werden?

    – Mitsch

    22. Januar 2016 um 10:45 Uhr

Sie können verwenden objdump dafür.

EDIT: Aus der Manpage:

-W
--dwarf
Displays  the  contents of the DWARF debug sections in the file, if
any are present.

  • Können Sie näher erläutern, wonach Sie in der Ausgabe von z. B. dsymutil -s? Bedeutet das Vorhandensein einer Ausgabe, dass sie mit Debug-Symbolen erstellt wurde, oder sollte sie gruppiert werden?

    – Mitsch

    22. Januar 2016 um 10:45 Uhr

Antworten, die die Verwendung von vorschlagen objdump --debugging oder readelf --debug-dump=... funktionieren nicht, wenn Debug-Informationen in einer von der Binärdatei getrennten Datei gespeichert sind, dh die Binärdatei enthält a Debug-Link Sektion. Vielleicht könnte man das einen Bug-In nennen readelf.

Der folgende Code sollte dies korrekt handhaben:

# Test whether debug information is available for a given binary
has_debug_info() {
  readelf -S "$1" | grep -q " \(.debug_info\)\|\(.gnu_debuglink\) "
}

Sehen Separate Debug-Dateien im GDB-Handbuch für weitere Informationen.

  • So, readelf -S example | grep debug wäre besser. So finden Sie die Linkdatei mit readelf --debug-dump=links example | grep link (GNU Readelf-Version 2.31.1-13.fc29)

    – Nick Dong

    10. August 2021 um 13:46 Uhr


1422510cookie-checkWie kann ich feststellen, ob eine Bibliothek mit -g kompiliert wurde?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy