Débogage léger sur Linux embarqué

Je développe une application qui s'exécute sur un petit SBC basé sur Linux (~ 32 Mo de RAM). Malheureusement, mon application est devenue trop grande pour fonctionner sous GDB. Est-ce que quelqu'un sait de toutes les bonnes méthodes de débogage léger que je peux utiliser dans Linux intégré? Même être capable de voir la trace d'une pile de thread serait extrêmement utile.Débogage léger sur Linux embarqué

Je dois mentionner que cette application est écrit en C++ et exécute plusieurs threads, donc gdbserver est un non-droit, car il ne fonctionne pas avec les applications multithread.

Merci à l'avance,

Maha

Source

2009-12-01 Maha

Etes-vous sûr gdbserver ne fonctionne pas pour les applications multithread? Cette page suggère que cela fonctionne: http://www.kegel.com/linux/gdbserver.html. –

gdbserver fonctionne vraiment avec des applications multi-thread, je travaille sur un projet embarqué avec> 25 threads et nous utilisons gdbserver tout le temps .

info threads

répertorie tous les fils du système

thread <thread number from info threads>

commutateurs pour que thread d'exécution.

thread apply XXX <command>

Fonctionne sur le thread désigné par XXX, qui peut également être 'all'. Donc, si vous voulez la trace de retour de toutes les discussions en cours d'exécution ne

thread apply all bt

Une fois que vous êtes dans le flux d'exécution d'un fils donné toutes vos commandes typiques fonctionnent comme ils le feraient dans un seul processus fileté.

Source

2009-12-03 00:21:24 asm

Dois-tu lancer gdb/gdbserver avec des arguments spéciaux? Je cours sur un processeur ARM. Lorsque je lance 'gdbserver localhost: 12345 myapp' puis exécute la même version de gdb sur mon hôte et saisis la commande 'target remote 10.0.150.92:12345', le débogueur est confus car il pense qu'un seul thread est en cours d'exécution chaque changement de contexte, et les «threads d'informations» ne signalent qu'un seul thread en cours d'exécution). – Maha

Je ne dois pas courir avec des arguments spéciaux quand je débogue, notre projet est également sur un ARM. Mon processus de débogage à distance semble le même que le vôtre. On cible: gdbserver localhost: 10000 monapp sur l'hôte: arm_v5t-le-gdb monapp sur la ligne de commande gdb hôte: cible à distance: Par la même version de gdb vous dire le bras droit de construire? Y at-il une raison pour que votre application reçoive des signaux tels que SIGUSR1/2 ou quelque chose pendant les changements de contexte? Cela provoquera l'arrêt du débogueur. L'application sur la cible et l'hôte doit être construite avec des symboles de débogage, nous NFS monter l'hôte pour cela. – asm

Mon ordinateur hôte est un système x86 et le système cible exécute un processeur ARM. Votre hôte est également un système ARM? Sinon, peut-être que j'ai manqué quelque chose dans mon build GDB (j'ai construit GDB 7.0 pour ARM, puis l'ai construit séparément pour x86). Mon application ne génère certainement pas SIGUSR1/2 - J'ai vérifié qu'il casse sur les changements de contexte car le débogueur pense qu'un seul thread est en cours d'exécution. – Maha

J'ai entendu parler de gens qui font des hacks comme exécutant l'application dans un émulateur comme QEMU puis en cours d'exécution GDB (ou des choses comme valgrind) à ce sujet. Il semble douloureux, mais si ça marche ....

Est-ce que vous mènera nulle part avec libunwind (pour obtenir des traces de pile) et l'exploitation forestière printf?

Source

2009-12-02 00:08:26

Merci pour les pointeurs.J'ai regardé courir sous un émulateur, mais c'est certainement une manière pénible d'aller et je mangerais probablement plus de temps que je peux dépenser. Je suis en train de faire une journalisation style printf, mais c'est une application assez complexe et il est parfois difficile de déterminer exactement quel composant cause un problème en premier lieu. Libunwind ressemble vraiment à un outil utile, je vais essayer. – Maha

impression port série est le poids le plus léger, je peux penser à ~~~ facilement vu dans un PC hôte, et le code de poids simple et la lumière dans votre application ~~

Si vous ne disposez pas d'un port série , une fois que nous avons utilisé un port GPIO et simulé un port série en l'utilisant. Cela a fonctionné parfaitement bien, mais était un peu lent :-(~~~

Source

2009-12-03 00:15:51 Alphaneo

Y a-t-il une raison pour laquelle vous avez construit votre propre débogueur? Je développe un système Linux en utilisant un processeur ARM (AT91SAM926x) et nous utilisons à la fois le compilateur et le débogueur de CodeSourcery. Je ne pense pas qu'ils aient déjà sorti une version avec GDB 7 mais je débogue des applications C++ multithread en utilisant l'outil gdbserver sans aucun problème.

Source

2009-12-07 20:56:08

Nous utilisons une chaîne d'outils fournie par notre fabricant SBC. Malheureusement, ils ne fournissent pas un GDB pré-construit, donc je suis tout seul. – Maha

Une chose que vous pourriez essayer est de construire une version plus ancienne de GDB. GDB 7 est très nouveau et j'ai lu quelques rapports de bugs majeurs (pas liés à ARM). Nous exécutons la version 6.7. –

Gdbserver fonctionne en effet avec des applications multithread. Cependant, vous devez compiler un débogueur cible pour votre hôte pour qu'il fonctionne avec votre cible gdb.

Voir cet article pour une description détaillée de la façon de le faire:

Remote cross-target debugging with GDB and GDBserver

Source

2009-12-09 20:50:47 mikelong

Merci pour le lien. J'ai suivi les instructions là mais elles n'ont pas fonctionné pour moi. Essayer de construire les binaires arm-natifs avec sa méthode a échoué - faire des matrices, se plaignant que le compilateur C ne peut pas générer d'exécutables. Je ne sais pas pourquoi, car le processus de construction de GDB est généralement assez intelligent pour ne pas tester les exécutables qu'il génère lors de la compilation croisée. – Maha

Débogage léger sur Linux embarqué

Répondre

Questions connexes