Jak mogę sprawdzić, czy biblioteka została skompilowana z opcją -g?

105

Mam kilka skompilowanych bibliotek na Linuksie x86 i chcę szybko ustalić, czy zostały skompilowane z symbolami debugowania.

c debugging gdb debug-symbols

— Dan Hook
źródło

86

Jeśli używasz systemu Linux, użyj objdump --debugging. Dla każdego pliku obiektowego w bibliotece powinien istnieć wpis. W przypadku plików obiektowych bez symboli debugowania zobaczysz coś takiego:

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

voidincr.o:     file format elf64-x86-64

Jeśli istnieją symbole debugowania, dane wyjściowe będą znacznie bardziej szczegółowe.

— Matt McClellan
źródło

5

Są też obdjump -W libi readelf -w lib. Ten ostatni jest bardziej konfigurowalny - zobacz stronę podręcznika readelf (1).

— przemoc

3

W przypadku dowolnego pliku binarnego (w tym skompilowanego z opcją -g) objdump daje mi odpowiedź „brak rozpoznanych informacji debugowania”, chyba że skompiluję go z opcją -gstabs. Wygląda na to, że jest to rozpoznany błąd.

— Dan Hook

Dan, na której platformie próbowałeś tego?

— swegi

Zatrudniony rosyjski: z man objdump (1) flaga --debugging "próbuje przeanalizować informacje o formacie debugowania STABS i IEEE przechowywane w pliku i wydrukować je przy użyciu składni podobnej do C. Jeśli żaden z tych formatów nie zostanie znaleziony, ta opcja nie zostanie znaleziona na opcji -W, aby wydrukować wszelkie informacje DWARF w pliku. "

— Matt McClellan,

5

objdump -gnie daje mi nic do prostego testu. o skompilowane zarówno z, jak i bez g, co skutecznie czyni go bezużytecznym. Ubuntu 12.04, gcc 4.6.3, GNU objdump 2.22. nm -awydaje się być bardziej przydatne.

— jw013

89

Sugerowane polecenie

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

daje mi zawsze ten sam wynik, przynajmniej na Ubuntu / Linaro 4.5.2:

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

bez względu na to, czy archiwum / biblioteka współdzielona została zbudowana z -gopcją czy bez niej

To, co naprawdę pomogło mi ustalić, czy -gzostało użyte, to narzędzie readelf :

readelf --debug-dump=decodedline libinspected.so

lub

readelf --debug-dump=line libinspected.so

To wypisze zestaw linii składający się z nazwy pliku źródłowego, numeru linii i adresu, jeśli takie informacje debugowania są zawarte w bibliotece , w przeciwnym razie nic nie wydrukuje .

Możesz przekazać dowolną wartość, którą uznasz za niezbędną dla --debug-dumpopcji zamiast decodedline.

— Alex InTechno
źródło

1

działa świetnie. Próbowałem tego polecenia na moim pliku wykonywalnym z pierwszym wydaniem CMAKE_BUILD_TYPE i polecenie zwróciło puste. Potem spróbowałem z CMAKE_BUILD_TYPE DEBUG i wtedy było całkiem sporo wyjścia.

— informacja z

34

Pomogło to:

gdb mylib.so

Wyświetla się, gdy nie znaleziono symboli debugowania:

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

Lub po znalezieniu:

Reading symbols from mylib.so...done.

Żadna z wcześniejszych odpowiedzi nie dawała miarodajnych wyników: biblioteki bez symboli debugowania dawały dużo danych wyjściowych itp.

— Velkan
źródło

Dzięki! U mnie to zadziałało, używając kompilatora clang w Androidzie z cmake :)

— Pär Nils Amsen

super świetne do szybkiego sprawdzenia! działa również na plikach obiektowych * .o.

— Stephane Rolland

28

nm -a <lib> wypisze wszystkie symbole z biblioteki, w tym symbole debugowania.

Możesz więc porównać wyniki nm <lib>i nm -a <lib>- jeśli się różnią, twoja biblioteka zawiera kilka symboli debugowania.

— qrdl
źródło

3

@ Zatrudniony rosyjski Czy możesz to rozwinąć? Jak myślisz, dlaczego to niewłaściwe narzędzie? Wykonuje swoją pracę i robi to również w systemie Linux.

— qrdl

Nawet dla wbudowanego linuxa opartego na jądrze 2.6.35, xxx-objdump, xxx-nm działa dobrze.

— agfe2

nm -ama alias, nm --debug-symsktóry jest oczywisty :-).

— pevik

3

Po prostu wpisz, diff <(nm <lib>) <(nm -a <lib>)aby uzyskać łatwą

— różnicę

17

Na OSX możesz używać dsymutil -si dwarfdump.

Użycie dsymutil -s <lib_file> | morespowoduje wyświetlenie ścieżek plików źródłowych w plikach, które mają symbole debugowania, ale w przeciwnym razie tylko nazwy funkcji.

— glennr
źródło

11

Czy możesz wyjaśnić, czego szukać na przykład w pracy dsymutil -s? Czy istnienie wyjścia oznacza, że zostało ono zbudowane przy użyciu symboli debugowania, czy powinno być grepowane?

— Mitch

12

Możesz do tego użyć objdump .

EDYCJA: Ze strony podręcznika:

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

— swegi
źródło

6

Odpowiedzi sugerujące użycie objdump --debugginglub readelf --debug-dump=...nie działają w przypadku, gdy informacje debugowania są przechowywane w pliku innym niż plik binarny, tj. Plik binarny zawiera sekcję łącza debugowania . Być może można to nazwać błędem readelf.

Poniższy kod powinien obsłużyć to poprawnie:

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

Aby uzyskać więcej informacji, zobacz Oddzielne pliki debugowania w podręczniku GDB.

— ACK
źródło