Come eseguire il debug di runtime delle librerie condivise?

Question

Qualcuno può dirmi come eseguire il debug di runtime su librerie condivise?

Devo eseguire il debug di runtime di una funzione nella mia libreria condivisa, ma viene chiamata da un altro programma. Come posso fare qualcosa come dbx con librerie condivise?

Sto usando dbx su AIX. gdb è meglio di dbx per quello che sto cercando di fare ?.

Answer 1

Devi solo chiamare gdb con l'eseguibile (non importa se è tuo o di terze parti). Ecco un esempio in cui eseguo il debug del comando ls e imposto un punto di interruzione nella (condivisa) libreria c . Questo esempio usa gdb 6.8 che supporta i punti di interruzione differiti (in sospeso) che lo rendono facile:

gdb /bin/ls
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(no debugging symbols found)
(gdb) b write
Function "write" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (write) pending.
(gdb) r
Starting program: /bin/ls
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
(no debugging symbols found)
[New Thread 0x7f98d2d23780 (LWP 7029)]
[Switching to Thread 0x7f98d2d23780 (LWP 7029)]

Breakpoint 1, 0x00007f98d2264bb0 in write () from /lib/libc.so.6
(gdb)

Come puoi vedere, gdb gestisce automaticamente tutti i thread utilizzati dall'eseguibile. Non devi fare nulla di speciale per i thread lì. Il punto di interruzione funzionerà in qualsiasi thread.

In alternativa, se si desidera collegare il debugger a un'applicazione già in esecuzione (uso come esempio tail -f / tmp / ttt ):

ps ux | grep tail
lothar    8496  0.0  0.0   9352   804 pts/3    S+   12:38   0:00 tail -f /tmp/ttt
lothar    8510  0.0  0.0   5164   840 pts/4    S+   12:39   0:00 grep tail

gdb
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(no debugging symbols found)
(gdb) attach 8496
Attaching to program: /usr/bin/tail, process 8496
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
[New Thread 0x7f24853f56e0 (LWP 8496)]
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/ld-linux-x86-64.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
(no debugging symbols found)
0x00007f2484d2bb50 in nanosleep () from /lib/libc.so.6
(gdb) b write
Breakpoint 1 at 0x7f2484d57bb0
(gdb) c
Continuing.
[Switching to Thread 0x7f24853f56e0 (LWP 8496)]

Breakpoint 1, 0x00007f2484d57bb0 in write () from /lib/libc.so.6
(gdb)

Answer 2

Normalmente la procedura per il debug di una libreria condivisa è molto simile a quella per il debug di un eseguibile - la differenza principale è che potresti non essere in grado di impostare un breakpoint fino a quando la libreria condivisa non viene caricata in memoria. Alleghi il debugger all'eseguibile principale.

Se si sta eseguendo il debug di un'applicazione che non è di proprietà dell'utente, ma si utilizza il modulo in un'architettura di plug-in, si utilizza comunque lo stesso metodo. Assicurati (come sempre) di avere informazioni di debug disponibili per la tua libreria condivisa. In Windows, potresti generare un file .pdb. Con gcc, penso che tu specifichi un flag di compilatore speciale (-g?) Per garantire che vengano fornite informazioni di debug. Alleghi il debugger all'applicazione di terze parti.

Answer 3

Un altro esempio della risposta di lothar:

Sto eseguendo dei test su una libreria dinamica test.so (compilata da test.c ) in Linux usando python e l'unità di python -testing library unittest chiamato tests / test_pwmbasic.py . (lo schema di denominazione è un po 'monotono, me ne rendo conto ora)

~/my/test/path/
    tests/
        __init__.py
        test_pwmbasic.py
    test.c
    test.so

Voglio eseguire il debug di ciò che è in test.so dallo stimolo in test_pwmbasic.py . Quindi è così che l'ho fatto funzionare ...

$ cd ~/my/test/path
$ gdb $(which python)
   ... gdb blah ...
(gdb) b test.c:179
(gdb) run
>>> from tests.test_pwmbasic import *
>>> import unittest
>>> unittest.main()
   ... unittest blah ...
Breakpoint 1, pwmTest_setDutyCycles (dutyCycles=0x7ffff7ece910) at ./test.c:179
(gdb) print pwm_errorCode
$1 = PWM_ERROR_NONE

e ora voglio sposare gdb

nota: test.c include anche ../pwm.c , quindi posso anche fare breakpoint all'interno di quella libreria con

(gdb) b pwm.c:123

Answer 4

Ricordo di aver testato le librerie condivise creando un'app finta che la utilizzava. Se sei disposto a fare molto lavoro, potresti creare una seconda libreria condivisa finta che raccoglie solo informazioni su come la libreria viene utilizzata dall'app di terze parti e quindi far sì che la tua app finta riproduca tali informazioni.

Naturalmente, non dubitare mai della potenza delle chiamate printf e fprintf ben posizionate.

Answer 5

È passato molto tempo da quando ho dovuto usare dbx su AIX e ho riscontrato anche questo problema. L'installazione di gdb non è stata un'opzione per me.

dbx  /path/to/your/program
(dbx) run [args to your program]
(dbx) set $ignoreonbptrap           # I kept hitting a trace/bpt trap
(dbx) set $deferevents              # allows setting bp in not loaded shared library
(dbx) set $repeat                   # useful, repeat commands with <enter> tjust like gdb
(dbx) stop in MySharedLibraryFunc   # defers breakpoint
(dbx) cont

Answer 6

Potresti provare a compilare e collegare staticamente la libreria per eseguire il debug.
Se il tuo bug viene visualizzato solo quando viene compilato come condiviso, questo potrebbe darti alcuni indizi.