Leichtes Debugging unter Embedded Linux

Ich entwickle eine Anwendung, die auf einem kleinen Linux-basierten SBC (~ 32MB RAM) läuft. Leider wurde meine App vor kurzem zu groß, um unter GDB zu laufen. Kennt jemand gute, leichte Debugging-Methoden, die ich in Embedded Linux verwenden kann? Es wäre sehr hilfreich, den Stack-Trace eines Threads anzeigen zu können.Leichtes Debugging unter Embedded Linux

Ich sollte erwähnen, dass diese Anwendung in C++ geschrieben ist und mehrere Threads ausführt, so gdbserver ist ein No-Go, wie es mit Multithread-Anwendungen nicht funktioniert.

Vielen Dank im Voraus,

Maha

Quelle

2009-12-01 Maha

Sind Sie sicher, gdbserver nicht für Multi-Thread-Anwendungen funktioniert? Diese Seite schlägt vor, dass es funktioniert: http://www.kegel.com/linux/gdbserver.html. –

gdbserver funktioniert definitiv mit Multi-Thread-Anwendungen, ich arbeite gerade an einem eingebetteten Projekt mit> 25 Threads und wir verwenden gdbserver die ganze Zeit .

info threads

listet alle Threads im System

thread <thread number from info threads>

schaltet auf diesem Ausführungs-Thread.

thread apply XXX <command>

Läuft auf dem durch XXX angegebenen Thread, der auch "all" sein kann. Also, wenn Sie die Rückverfolgung von allen ausgeführten Threads wollen tun

thread apply all bt

Sobald Sie in der Ausführungsablauf eines gegebenen Threads alle typischen Befehle sind funktionieren, wie sie es in einem Single-Threaded-Prozess.

Quelle

2009-12-03 00:21:24 asm

Müssen Sie gdb/gdbserver mit speziellen Argumenten ausführen? Ich laufe auf einem ARM-Prozessor. Wenn ich 'gdbserver localhost: 12345 myapp' starte und dann dieselbe Version von gdb auf meinem Host ausführe und den Befehl 'target remote 10.0.150.92:12345' eintrage, wird der Debugger verwirrt, da er denkt, dass nur ein Thread läuft (bricht mit jeder Kontextwechsel und "Info-Threads" meldet nur einen laufenden Thread). – Maha

Ich muss nicht mit speziellen Argumenten laufen, wenn ich debugge, unser Projekt ist auch auf einem ARM. Mein Prozess zum Debuggen aus der Ferne klingt genauso wie bei Ihnen. Auf Ziel: gdbserver localhost: 10000 myapp Auf host: arm_v5t-le-GDB myapp Auf Host-GDB-Befehlszeile: Zielfern : Durch die gleiche Version von GDB meinen Sie den Arm richtig bauen? Gibt es einen Grund, warum Ihre App Signale wie SIGUSR1/2 oder etwas während Kontextwechsel erhalten würde? Das wird den Debugger beenden. Die Anwendung auf dem Ziel und Host muss mit Debug-Symbolen gebaut werden, wir NFS mounten den Host dafür. – asm

Meine Host-Maschine ist ein x86-System, und auf dem Zielsystem wird ein ARM-Prozessor ausgeführt. Ist Ihr Host auch ein ARM-System? Wenn nicht, habe ich vielleicht etwas in meinem GDB-Build verpasst (ich habe GDB 7.0 für ARM erstellt und dann für x86 separat erstellt). Meine App generiert definitiv kein SIGUSR1/2 - Ich habe überprüft, dass es bei Kontextwechsel bricht, da der Debugger denkt, dass nur ein Thread ausgeführt wird. – Maha

Ich habe von Leuten gehört Hacks wie die Ausführung der Anwendung in einem Emulator wie QEMU und dann GDB läuft (oder Dinge wie valgrind) auf, das zu tun. Es klingt schmerzhaft, aber wenn es funktioniert ....

Würden Sie irgendwo mit libunwind (um Stack-Traces zu bekommen) und printf-style-Logging bekommen?

Quelle

2009-12-02 00:08:26

Danke für die Zeiger.Ich sah unter einem Emulator laufen, aber das ist definitiv eine schmerzhafte Art zu gehen und würde wahrscheinlich mehr Zeit aufessen, als ich ausgeben kann. Ich mache printf-style-Protokollierung jetzt, aber das ist eine ziemlich komplexe Anwendung, und es ist manchmal schwierig, genau herauszufinden, welche Komponente in erster Linie ein Problem verursacht. Libunwind sieht definitiv wie ein hilfreiches Werkzeug aus, ich werde es versuchen. – Maha

Serielle Schnittstelle Druck ist das meiste Licht Gewicht, das ich von ~~~ denken kann leicht in einem Host-PC zu sehen ist, und einfach und leicht Code in Ihrer Anwendung ~~

Wenn Sie nicht über eine serielle Schnittstelle , nachdem wir einen GPIO-Port verwendet und einen seriellen Port simuliert haben. Es funktionierte perfekt, aber war ein bisschen langsam :-(~~~

Quelle

2009-12-03 00:15:51 Alphaneo

Gibt es einen Grund, warum Sie Ihren eigenen Debugger erstellt haben? Ich entwickle ein Linux-System mit einem ARM-Prozessor (AT91SAM926x) und wir verwenden sowohl Compiler als auch Debugger von CodeSourcery. Ich glaube nicht, dass sie eine Version mit GDB 7 veröffentlicht haben, aber ich debugge Multithread-C++ - Anwendungen mit dem gdbserver-Tool ohne Probleme.

Quelle

2009-12-07 20:56:08

Wir verwenden eine Toolchain, die von unserem SBC-Hersteller geliefert wird. Leider liefern sie keine vorgefertigte GDB, also bin ich alleine. – Maha

Sie könnten versuchen, eine ältere Version von GDB zu erstellen. GDB 7 ist sehr neu und ich habe einige Berichte über größere Bugs gelesen (allerdings nicht mit ARM). Wir führen Version 6.7. –

Gdbserver funktioniert tatsächlich mit Multithread-Anwendungen. Allerdings müssen Sie einen Cross-Target-Debugger für Ihren Host kompilieren, damit er mit Ihrem Ziel-gdb funktioniert.

in diesem Artikel für eine detaillierte Beschreibung, wie es geht:

Remote cross-target debugging with GDB and GDBserver

Quelle

2009-12-09 20:50:47 mikelong

Danke für den Link. Ich folgte den Anweisungen dort, aber sie arbeiteten nicht für mich. Der Versuch, die arm-native Binärdateien mit seiner Methode zu erstellen, ist fehlgeschlagen - make stirbt und beklagt sich, dass der C-Compiler keine ausführbaren Dateien generieren kann. Ich weiß nicht, warum das so ist, da der Build-Prozess von GDB normalerweise schlau genug ist, um ausführbare Dateien nicht zu testen, die beim Cross-Compilieren generiert werden. – Maha

Antwort

Verwandte Themen