Estoy usando gdb 7.4.1 en el destino powerpc incorporado para realizar un análisis en mi programa de C ++ de múltiples subprocesos que utiliza pthreads. Mi objetivo final es escribir gdb con python para automatizar algunas funciones de análisis comunes. El problema es que estoy encontrando alguna discrepancia en el comportamiento cuando ejecuto comandos individualmente en un comando gdb definido por el usuario (o invoco los mismos comandos a través de un script de python).

edición: he encontradoesta referencia a un problema muy similar en la lista de correo principal de gdb. Aunque no sigo completamente la respuesta de Pedro sobre la limitación del modo asíncrono, creo que está implicando que en el modo asíncrono, no se puede confiar en el tiempo relativo de las secuencias de comandos definidas por el usuario. Esto es lo que encontré empíricamente.

En ambos escenarios, realizo los siguientes pasos de inicio, cargando mi programa, configurando sus argumentos y activando los modos de depuración asíncronos y sin interrupciones, luego ejecutando el programa en segundo plano:

(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 &

En este punto, si emito manualmenteinterrupt y entoncesinfo threads comandos, veo la lista de todos los subprocesos en ejecución excepto uno que se detuvo. Entonces you puedocontinue & y repetir a mi corazón contenido, funciona de manera consistente. Cuando se detiene, puedo inspeccionar los marcos de pila de ese hilo y todo está bien.

Sin embargo, si en cambio pongo estos comandos en un comando gdb definido por el usuario:

(gdb) define foo
(gdb) interrupt
(gdb) info threads
(gdb) continue &
(gdb) end
(gdb) foo
Cannot execute this command while the selected thread is running.

Luego, la lista de hilos impresa por foo indica que no se detuvieron los hilos, por lo quecontinue & comando devuelveCannot execute this command while the selected thread is running.. Pensé que este era un problema inherente al comando asíncrono de gdb, así que inserté una espera absurdamente larga después del comando de interrupción y obtuve el mismo comportamiento:

(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 sin el comando de suspensión, siempre puedo emitir los comandos de CLI manuales y los subprocesos se detienen correctamente.

De manera similar, obtengo los mismos resultados al obtener una secuencia de comandos de Python para hacer la lectura del hilo:

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 &")

Obtengo el mismo resultado incluso si especificofrom_tty=True en elgdb.execute llamadas Además, si usocontinue -a suprime la cadena de error, pero no ayuda de lo contrario porque la llamada de interrupción aún no funciona.

Asi es esto:

error en la cabina? ¿Hay algo que estoy omitiendo o haciendo incorrectamente, dado lo que estoy tratando de lograr? ¿Debería esto funcionar, o tengo que usar GDB / MI para "manejar" gdb de forma asíncrona?un problema de tiempo? Tal vez invocandoshell sleep (opython time.sleep()) no hace lo que asumo que haría, en este contexto.¿Problema con mi uso de pthreads? He asumido que, dado que el uso manual de los comandos gdb siempre funciona correctamente, este no es el caso.un problema de gdb?

Gracias.