2012-04-03 19 views
47

Versione breve della domanda: Come posso ottenere gdb per utilizzare i simboli di debug per libc? VersioneCome utilizzare la versione di debug di libc

più lunga: Sto debug di un programma con gdb e voglio vedere informazioni su un futex usato da libc. Tuttavia, ad un certo punto durante il debug ottengo in uscita come ad esempio:

Catchpoint 2 (call to syscall futex), 0x00007ffff772b73e in ??() from /lib/libc.so.6 
(gdb) bt 
#0 0x00007ffff772b73e in ??() from /lib/libc.so.6 
#1 0x00007ffff767fb90 in ??() from /lib/libc.so.6 
#2 0x00007ffff767a4c0 in vfprintf() from /lib/libc.so.6 
#3 0x00007ffff768565a in printf() from /lib/libc.so.6 
.... 

Quando eseguo info sharedlibrary in gdb al punto di interruzione che vedo:

(gdb) info sharedlibrary 
From    To     Syms Read Shared Object Library 
0x00007ffff7dddaf0 0x00007ffff7df6704 Yes (*)  /lib64/ld-linux-x86-64.so.2 
0x00007ffff7bc53e0 0x00007ffff7bd1388 Yes (*)  /lib/libpthread.so.0 
0x00007ffff79ba190 0x00007ffff79bd7d8 Yes (*)  /lib/librt.so.1 
0x00007ffff76538c0 0x00007ffff7766c60 Yes (*)  /lib/libc.so.6 
0x00007ffff6c1fd80 0x00007ffff6c303c8 Yes (*)  /lib/libgcc_s.so.1 
(*): Shared library is missing debugging information. 

E quando corro ldd vedo:

linux-vdso.so.1 => (0x00007ffff7fde000) 
libpthread.so.0 => /lib/libpthread.so.0 (0x00007ffff7dbf000) 
librt.so.1 => /lib/librt.so.1 (0x00007ffff7bb6000) 
libc.so.6 => /lib/libc.so.6 (0x00007ffff7833000) 
/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fdf000) 

Sto usando Ubuntu 10.04 e penso che la versione di libc con i simboli di debug sia in /usr/lib/debug/lib. Ho provato a impostare la mia variabile LD_LIBRARY_PATH per avere questo nella parte anteriore del percorso, ma questo non sembrava fare la differenza.

Non sono completamente chiaro su come il programma sceglie quali librerie condivise caricare, se questo è impostato in fase di esecuzione o in fase di compilazione (ho una sorta di runtime ipotizzato ma ora non ne sono sicuro). Le informazioni su come ottenere gdb per usare la versione di debug di libc sono apprezzate.

risposta

57

Penso che la versione di libc con i simboli di debug sia in/usr/lib/debug/lib. Ho provato a impostare la mia variabile LD_LIBRARY_PATH per avere questo nella parte anteriore del percorso, ma ciò non sembrava fare la differenza.

Questi sono non i droidi che stai cercando.

Le librerie in/usr/lib/debug non sono librerie reali. Piuttosto, contiene solo informazioni di debug ma non contengono le sezioni .text e .data del numero reale libc.so.6. È possibile leggere i file debuginfo separati here.

I file in /usr/lib/debug provengono da libc6-dbg pacchetto e GDB li caricherà automaticamente , fintanto che corrispondono alla tua installata libc6 versione. Se il tuo libc6 e libc6-dbg non corrispondono, dovresti ricevere un avviso da GDB.

È possibile osservare i file che GDB sta tentando di leggere impostando set verbose on. Ecco cosa si dovrebbe vedere quando libc6 e libc6-dbg corrispondono:

(gdb) set verbose on 
(gdb) run 
thread_db_load_search returning 0 
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.11.1.so...done. 
thread_db_load_search returning 0 
done. 
thread_db_load_search returning 0 
Loaded symbols for /lib64/ld-linux-x86-64.so.2 
Reading symbols from system-supplied DSO at 0x7ffff7ffb000...done. 
WARNING: no debugging symbols found in system-supplied DSO at 0x7ffff7ffb000. 
thread_db_load_search returning 0 
Reading in symbols for dl-debug.c...done. 
Reading in symbols for rtld.c...done. 
Reading symbols from /lib/librt.so.1...Reading symbols from /usr/lib/debug/lib/librt-2.11.1.so...done. 
thread_db_load_search returning 0 
... etc ... 

Aggiornamento:

Per esempio vedo
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done

Ciò implica che il GDB non sta cercando /usr/lib/debug . Un modo che potrebbe accadere è se si imposta debug-file-directory nel proprio .gdbinit in modo errato.

Qui è l'impostazione predefinita:

(gdb) show debug-file-directory 
The directory where separate debug symbols are searched for is "/usr/lib/debug". 
+0

grazie per la risposta alla mia domanda. Sembra che abbia qualche altro problema perché quando accendo l'output prolisso non vedo gdb che cerca '/ usr/lib/debug' per i simboli per libc. Per esempio vedo 'Simboli di lettura da /lib/libc.so.6...(non trovato il debugging dei simboli) ... fatto. Quindi ho ancora qualche problema, ma la tua risposta è molto utile per capire cosa il vero problema è –

+3

grazie per l'aggiornamento. Avevo scaricato e installato gdb 7.4 dal sorgente nella mia home directory perché aveva una correzione di bug che risolveva un problema che avevo con gdb 7.1, ma non ho il permesso di aggiornare la versione di gdb sul mio sistema. Ad ogni modo la 'debug-files-directory' non è stata impostata correttamente ma l'impostazione corretta in' .gdbinit' sembra risolvere il problema. –

+0

Inoltre, per accedere alle funzioni di libc in gdb, assicurarsi di scaricare il codice sorgente di glibc e decomprimerlo. Quindi esegui il comando gdb 'directory' con il percorso all'origine. Se stai eseguendo una distribuzione che applica patch a libc (come Debian), assicurati di applicare le stesse patch (ad esempio eseguendo 'debuild'), altrimenti i numeri di riga di origine potrebbero non corrispondere. –

13

assicurarsi di aver installato i simboli di debug per libc:

sudo apt-get install libc6-dbg 

E se siete su un codice x86 debug sistema x64:

sudo apt-get install libc6:i386 
sudo apt-get install libc6-dbg:i386