Utilizzo gdb 7.4.1 su target powerpc incorporato per eseguire alcune analisi sul mio programma C++ multi-threaded che utilizza pthreads. Il mio obiettivo finale è quello di script gdb con python per automatizzare alcune funzioni di analisi comuni. Il problema è che sto riscontrando una certa discrepanza nel comportamento quando eseguo i comandi individualmente vs in un comando definito dall'utente gdb (o invocando gli stessi comandi tramite script python).Il thread C++ non si interrompe in modalità asincrona gdb utilizzando la sequenza di comando definita dall'utente o python
modifica: Ho trovato il riferimento this a un problema molto simile nella mailing list principale di gdb. Sebbene io non segua completamente la risposta di Pedro riguardo alla limitazione della modalità asincrona, penso che implichi che in modalità asincrona, il tempo relativo delle sequenze di comando definite dall'utente non può essere considerato attendibile. Questo è quello che ho trovato empiricamente.
In entrambi gli scenari, mi effettuare le seguenti operazioni di start-up, di caricare il mio programma, impostando le sue args, e girando sulle modalità di debug asincroni e non-stop, quindi eseguire il programma in background:
(gdb) file myprogram
(gdb) set args --interface=eth0 --try-count=0
(gdb) set target-async on
(gdb) set pagination off
(gdb) set non-stop on
(gdb) run &
A questo punto, se immetto manualmente i comandi interrupt e poi info threads, vedo l'elenco di tutti i thread in esecuzione tranne uno che è stato arrestato. Quindi posso continue & e ripetere il contenuto del mio cuore, funziona in modo coerente. Quando viene fermato, posso ispezionare i frame di stack di quel thread e tutto va bene.
Tuttavia, se invece metto questi comandi in un comando gdb definito dall'utente:
(gdb) define foo
(gdb) interrupt
(gdb) info threads
(gdb) continue &
(gdb) end
(gdb) foo
Cannot execute this command while the selected thread is running.
Poi l'elenco filo stampato da pippo indica filetti sono stati fermati, e così le continue & comando restituisce Cannot execute this command while the selected thread is running.. Ho pensato che questo era un problema inerente al gdb asincrono comando, quindi ho inserito un assurdamente lunga attesa dopo il comando di interruzione ed ho ottenuto lo stesso comportamento:
(gdb) define foo
(gdb) interrupt
(gdb) shell sleep 5
(gdb) info threads
(gdb) continue &
(gdb) end
(gdb) foo
Cannot execute this command while the selected thread is running.
Con o senza il comando del sonno, posso sempre rilasciare il manuale Comandi CLI e i thread vengono arrestati correttamente.
Allo stesso modo, ottengo gli stessi risultati di sourcing uno script python per fare il filo lettura:
import gdb, time
gdb.execute("file myprogram")
gdb.execute("set args --interface=eth0 --try-count=0")
gdb.execute("set target-async on")
gdb.execute("set pagination off")
gdb.execute("set non-stop on")
gdb.execute("run &")
time.sleep(5)
gdb.execute("interrupt")
# here, I inspect threads via gdb module interface
# in practice, they're always all running bc the program neven got interrupted
for thread in gdb.selected_inferior().threads():
print thread.is_running(),
gdb.execute("continue &")
ottengo lo stesso risultato, anche se a specificare from_tty=True nelle gdb.execute chiamate. Inoltre, se utilizzo continue -a, elimina la stringa di errore ma non aiuta altrimenti la chiamata a interrupt continua a non funzionare.
Quindi ... è questo:
- errore della cabina di guida? C'è qualcosa che sto omettendo o facendo in modo errato, dato quello che sto cercando di realizzare? Dovrebbe questo lavoro, o devo usare GDB/MI per asincronicamente "guidare" gdb in questo modo?
- un problema di temporizzazione? Forse invocare
shell sleep(opython time.sleep()) non fa ciò che presumo sarebbe, in questo contesto. - problema con il mio utilizzo di pthreads? Ho assunto che, dal momento che usare i comandi gdb manuali funzioni sempre correttamente, non è questo il caso.
- un problema gdb?
Grazie.