Depuración ligera en Linux incorporado

Estoy desarrollando una aplicación que se ejecuta en un pequeño SBC basado en Linux (~ 32MB de RAM). Tristemente, mi aplicación recientemente se volvió demasiado grande para funcionar bajo GDB. ¿Alguien sabe de algún método de depuración bueno y liviano que pueda usar en Linux embebido? Incluso poder ver el seguimiento de la pila de un hilo sería extremadamente útil.Depuración ligera en Linux incorporado

Debo mencionar que esta aplicación está escrita en C++ y ejecuta múltiples subprocesos, por lo que gdbserver es un no-go, ya que no funciona con aplicaciones multiproceso.

Gracias de antemano,

Maha

Fuente

2009-12-01 Maha

¿Seguro gdbserver no funciona para aplicaciones multiproceso? Esta página sugiere que funciona: http://www.kegel.com/linux/gdbserver.html. –

gdbserver definitivamente funciona con aplicaciones de subprocesos múltiples, estoy trabajando en un proyecto integrado ahora con> 25 hilos y usamos gdbserver todo el tiempo .

info threads

listas de todos los hilos en el sistema

thread <thread number from info threads>

interruptores para que hilo de ejecución.

thread apply XXX <command>

Se ejecuta en el hilo designado por XXX, que también puede ser 'todo'. Así que si desea que el rastreo de origen de todos los subprocesos que se ejecutan hacer

thread apply all bt

Una vez que estás en el flujo de ejecución de un determinado hilos de todos los comandos típicos funcionan como lo harían en un único proceso de roscado.

Fuente

2009-12-03 00:21:24 asm

¿Tienes que ejecutar gdb/gdbserver con argumentos especiales? Estoy ejecutando un procesador ARM. Cuando ejecuto 'gdbserver localhost: 12345 myapp' y luego ejecuto la misma versión de gdb en mi host e ingreso el comando 'target remote 10.0.150.92:12345', el depurador se confunde ya que piensa que solo se está ejecutando un subproceso (rompe con cada cambio de contexto e 'hilos de información' informan solo 1 hilo en ejecución). – Maha

No tengo que ejecutar argumentos especiales cuando depuro, nuestro proyecto también está en un ARM. Mi proceso para la depuración remota suena igual que el tuyo. a puerta: gdbserver localhost: 10000 miaplicacion En el host: miaplicacion arm_v5t-le-BGF En la línea de comandos de GDB anfitrión: destino remoto : Por misma versión de GDB quiere decir construir el brazo derecho? ¿Hay alguna razón por la que su aplicación reciba señales como SIGUSR1/2 o algo así durante los cambios de contexto? Eso hará que el depurador se detenga. La aplicación tanto en el destino como en el host debe construirse con símbolos de depuración, nosotros NFS montamos el host para eso. – asm

Mi máquina host es un sistema x86 y el sistema de destino ejecuta un procesador ARM. ¿Su anfitrión también es un sistema ARM? Si no, tal vez me perdí algo en mi compilación de GDB (construí GDB 7.0 para ARM, luego lo construí por separado para x86). Definitivamente, mi aplicación no está generando SIGUSR1/2. He verificado que se está rompiendo un cambio de contexto, ya que el depurador cree que solo se está ejecutando un subproceso. – Maha

que he oído de la gente que hace los cortes como el funcionamiento de la aplicación en un emulador QEMU como GDB y luego ejecutar (o cosas como valgrind) sobre eso. Suena doloroso, pero si funciona ...

¿Llegaría a algún lado con libunwind (para obtener rastros de pila) y con el estilo de impresión?

Fuente

2009-12-02 00:08:26

Gracias por los consejos.Miré correr bajo un emulador, pero definitivamente es una forma dolorosa de ir y probablemente me tomaría más tiempo de lo que puedo gastar. Estoy haciendo un registro al estilo de impresión en este momento, pero esta es una aplicación bastante compleja y, a veces, es complicado determinar qué componente causa un problema en primer lugar. Libunwind definitivamente parece una herramienta útil, lo intentaré. – Maha

impresión de puerto de serie es el peso más ligero que puedo pensar ~~~ ve fácilmente en un PC anfitrión, y el código de peso simple y ligero dentro de su aplicación ~~

Si usted no tiene un puerto serie , una vez que usamos un puerto GPIO y simulamos un puerto serie usándolo. Funcionó perfectamente, pero fue un poco lento :-(~~~

Fuente

2009-12-03 00:15:51 Alphaneo

¿Hay alguna razón por la que haya creado su propio depurador? Estoy desarrollando un sistema Linux usando un procesador ARM (AT91SAM926x) y estamos usando el compilador y el depurador de CodeSourcery. No creo que hayan lanzado una versión con GDB 7 todavía, pero estoy depurando aplicaciones multiproceso de C++ utilizando la herramienta gdbserver sin ningún problema.

Fuente

2009-12-07 20:56:08

Estamos utilizando una cadena de herramientas suministrada por nuestro fabricante de SBC. Desafortunadamente no suministran un GDB preconstruido, entonces estoy solo. – Maha

Una cosa que podrías intentar es construir una versión anterior de GDB. GDB 7 es muy nuevo y he leído algunos informes de errores importantes (aunque no relacionados con ARM). Estamos ejecutando la versión 6.7. –

Gdbserver sí funciona con aplicaciones multiproceso. Sin embargo, necesita compilar un depurador de destino cruzado para que su host lo haga funcionar con su gdb objetivo.

Consulte este artículo para obtener una descripción detallada de cómo hacerlo:

Remote cross-target debugging with GDB and GDBserver

Fuente

2009-12-09 20:50:47 mikelong

Gracias por el enlace. Seguí las instrucciones pero no funcionaron para mí. Tratando de construir los binarios nativos del brazo con su método fallido: hacer matrices, quejándose de que el compilador de C no puede generar ejecutables. No sé por qué lo hace, ya que el proceso de compilación de GDB suele ser lo suficientemente inteligente como para no probar los ejecutables que genera al compilar de forma cruzada. – Maha

Depuración ligera en Linux incorporado

Respuesta

Cuestiones relacionadas