Debug leggero su Linux embedded

Sto sviluppando un'applicazione che funziona su un piccolo SBC basato su Linux (~ 32 MB di RAM). Purtroppo, recentemente la mia app è diventata troppo grande per essere eseguita con GDB. Qualcuno sa di qualche buon metodo di debugging leggero che posso usare in Linux embedded? Anche essere in grado di visualizzare la traccia di stack di un thread sarebbe estremamente utile.Debug leggero su Linux embedded

Dovrei menzionare che questa applicazione è scritta in C++ ed esegue più thread, quindi gdbserver è un no-go in quanto non funziona con le applicazioni multithread.

Grazie in anticipo,

Maha

fonte

2009-12-01 Maha

Sei sicuro gdbserver non funziona per le applicazioni multithreaded? Questa pagina suggerisce che funziona: http://www.kegel.com/linux/gdbserver.html. –

gdbserver funziona sicuramente con le applicazioni multi-thread, sto lavorando su un progetto embedded adesso con> 25 thread e usiamo gdbserver tutto il tempo .

info threads

elenca tutti i fili del sistema

thread <thread number from info threads>

interruttori a quel filo di esecuzione.

thread apply XXX <command>

Esegue il thread indicato da XXX, che può anche essere "tutto". Quindi, se volete la traccia di ritorno da tutti i thread in esecuzione fare

thread apply all bt

Una volta entrato nel flusso di esecuzione di un dato thread tutti i comandi tipici lavorano come farebbero in un unico processo filettato.

fonte

2009-12-03 00:21:24 asm

Devi eseguire gdb/gdbserver con argomenti speciali? Sono in esecuzione su un processore ARM. Quando eseguo 'gdbserver localhost: 12345 myapp' e poi eseguo la stessa versione di gdb sul mio host e inserisco il comando 'target remoto 10.0.150.92:12345', il debugger viene confuso poiché crede che sia in esecuzione un solo thread (interruzioni con ogni interruttore di contesto e 'thread informativi' riporta solo 1 thread in esecuzione). – Maha

Non ho bisogno di eseguire argomenti speciali quando eseguo il debug, il nostro progetto è anche su un ARM. Il mio processo di debug in remoto suona uguale al tuo. Sull'obiettivo: gdbserver localhost: 10000 myapp sull'host: myapp arm_v5t-le-gdb Sulla riga di comando gdb host: destinazione remota : By stessa versione di gdb si intende il braccio destro a costruire? C'è qualche ragione per cui la tua app riceverebbe segnali come SIGUSR1/2 o qualcosa del genere durante gli switch di contesto? Ciò causerà l'arresto del debugger. L'applicazione su target e host deve essere costruita con simboli di debug, noi NFS montiamo l'host per quello. – asm

Il mio computer host è un sistema x86 e il sistema di destinazione esegue un processore ARM. Il tuo host è anche un sistema ARM? In caso contrario, forse mi mancava qualcosa nel mio build GDB (ho costruito GDB 7.0 per ARM, quindi lo ho compilato separatamente per x86). La mia app non sta sicuramente generando SIGUSR1/2 - Ho verificato che si sta infrangendo sugli switch di contesto poiché il debugger pensa che sia in esecuzione solo un thread. – Maha

Ho sentito parlare di persone che fanno hack come eseguire l'applicazione in un emulatore come QEMU e quindi eseguendo GDB (o cose del genere valgrind) su questo. Sembra doloroso, ma se funziona ...

Vuoi arrivare ovunque con libunwind (per ottenere tracce di stack) e la registrazione in stile printf?

fonte

2009-12-02 00:08:26

Grazie per i suggerimenti.Ho guardato correre sotto un emulatore, ma questo è sicuramente un modo doloroso per andare e probabilmente mangerei più tempo di quello che posso spendere. Al momento sto eseguendo la registrazione in stile printf, ma questa è un'applicazione abbastanza complessa ed è talvolta difficile individuare esattamente quale componente abbia causato un problema in primo luogo. Libunwind sembra decisamente uno strumento utile, darò un colpo. – Maha

stampa porta seriale è il peso più leggero che posso pensare ~~~ facilmente visto in un PC host, e il codice di peso semplice e leggero all'interno della vostra app ~~

Se non si dispone di una porta seriale , una volta abbiamo usato una porta GPIO e simulato una porta seriale che lo utilizzava. Ha funzionato perfettamente, ma è stato un po 'lento :-(~~~

fonte

2009-12-03 00:15:51 Alphaneo

C'è un motivo per cui hai creato il tuo debugger? Sto sviluppando un sistema Linux utilizzando un processore ARM (AT91SAM926x) e stiamo utilizzando sia il compilatore che il debugger da CodeSourcery. Non penso che abbiano già rilasciato una versione con GDB 7, ma sto eseguendo il debug di applicazioni C++ multithread utilizzando lo strumento gdbserver senza problemi.

fonte

2009-12-07 20:56:08

Stiamo usando una toolchain fornita dal nostro produttore SBC. Sfortunatamente non forniscono un GDB pre-costruito, quindi sono da solo. – Maha

Una cosa che potresti provare è creare una versione precedente di GDB. GDB 7 è molto nuovo e ho letto alcune segnalazioni di bug importanti (non correlati a ARM). Stiamo eseguendo la versione 6.7. –

Gdbserver funziona effettivamente con applicazioni multithread. Tuttavia è necessario compilare un debugger cross-target per il tuo host per farlo funzionare con il tuo target gdb.

consulta questo articolo per una descrizione dettagliata di come farlo:

Remote cross-target debugging with GDB and GDBserver

fonte

2009-12-09 20:50:47 mikelong

Grazie per il link. Ho seguito le istruzioni lì ma non hanno funzionato per me. Cercando di costruire i binari nativi di arm con il suo metodo fallito - fai morire, lamentando che il compilatore C non può generare eseguibili. Non so perché lo faccia, dato che il processo di compilazione di GDB è in genere abbastanza intelligente da non testare gli eseguibili che genera durante la compilazione incrociata. – Maha

Debug leggero su Linux embedded

risposta

Problemi correlati