Jak sprawdzić, czy program został skompilowany z symbolami debugowania? [duplikat]

to pytanie ma już odpowiedzi tutaj : Skąd mogę wiedzieć, czy biblioteka została skompilowana z-g? (7 odpowiedzi) Zamknięty 4 lata temu . GIMP jest GIMP-em z włączonymi symbolami debugowania, dlatego chciałbym prześledzić jakiś kod w GIMP-ie. Nie pamiętam, czy włączyłem je podczas kompilacji. Jak to sprawdzić bez rekompilacji programu?
Author: Lukasz Czerwinski, 2010-07-19

2 answers

Możesz używać file i objdump na Linuksie. W szczególności możesz sprawdzić, czy plik mówi "stripped"lub" not stripped " (pod moim Ubuntu 20.04.1 LTS, czy plik wykonywalny jest kompilowany z -g, czy nie pokazuje not stripped z file. Ale ten z -g, pokazuje with debug_info, oprócz tego), i czy objdump --syms wyświetla cokolwiek użytecznego (dla mnie mówi "brak symboli" dla zwykłej kompilacji).

 86
Author: Matthew Flaschen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-11-28 10:29:40

Podczas uruchamiania polecenia objdump --syms widzę znacznie więcej niż "no symbols" w wyjściu (przynajmniej dla obiekty jądra).

Aby sprawdzić, czy wewnątrz obiektu jądra znajdują się informacje o debugowaniu, możesz dodać na końcu polecenia objdump: | grep debug.

Jeśli ten łańcuch zostanie znaleziony, to wiadomo, że obiekt jądra zawiera informacje o debugowaniu. Jeśli nie, to jest to" czysty " obiekt jądra.

Przykład modułu jądra, który skompilowałem BEZ informacji o debugowaniu:

geertvc@jimi:~/mystuff/kernels/linux-3.12.6$ objdump --syms ./modules/lib/modules/3.12.6/kernel/drivers/i2c/busses/i2c-at91.ko | grep debug

Przykład tego samego modułu jądra, który skompilowałem z informacjami o debugowaniu:

geertvc@jimi:~/mystuff/kernels/linux-3.12.6$ objdump --syms ./modules/lib/modules/3.12.6/kernel/drivers/i2c/busses/i2c-at91.ko | grep debug
00000000 l    d  .debug_frame   00000000 .debug_frame
00000000 l    d  .debug_info    00000000 .debug_info
00000000 l    d  .debug_abbrev  00000000 .debug_abbrev
00000000 l    d  .debug_loc     00000000 .debug_loc
00000000 l    d  .debug_aranges 00000000 .debug_aranges
00000000 l    d  .debug_ranges  00000000 .debug_ranges
00000000 l    d  .debug_line    00000000 .debug_line
00000000 l    d  .debug_str     00000000 .debug_str
00000010 l       .debug_frame   00000000 $d

Jak widzisz, pierwsze wyjście nie zwraca nic, podczas gdy drugie wyjście zwraca linie z debug.

Uwaga: w moim przypadku, file polecenie zwróciło mi "nie rozebrane" w ZARÓWNO debugowanie i non-debug case. Jednak różnica w wielkości obiektu jądra była niezwykła:

  • ok. 16k bez informacje o debugowaniu
  • ok. 137k z informacjami o debugowaniu

Najwyraźniej ta ostatnia wersja miała w środku informacje o debugowaniu.

Moje pytanie: czy polecenie file jest wiarygodne w takich przypadkach? Z tego, czego doświadczyłem, polegam na komendzie objdump --syms ... | grep debug.

 59
Author: GeertVc,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-10-09 05:51:03