Question

J'ai à tester un certain code de bas niveau sur une architecture ARM. En règle générale expérimentation est assez compliquée sur le tableau réel, donc je pensais à QEMU.

Ce que je voudrais obtenir est une sorte d'informations de débogage comme printfs ou gdb. Je sais que cela est simple avec linux car il implémente à la fois le pilote de périphérique pour l'intégrateur QEMU et la fonction gdb, mais je ne travaille pas avec Linux. Aussi je pense que l'extraction de ce genre de fonctionnalité à partir du code source du noyau Linux serait compliqué.

Je suis à la recherche d'un système simple, exploitation qui implémente déjà l'une de ces caractéristiques. Avez-vous des conseils?

Était-ce utile?

La solution

Vous n'avez pas besoin d'un système d'exploitation cible au code de débogage qui est en cours d'exécution dans QEMU -. QEMU fait déjà pour vous

Plus précisément, QEMU supporte le débogage à distance de GDB - vous pouvez exécuter QEMU avec les options de ligne de commande appropriées et il exporter une interface qu'une copie de GDB (en cours d'exécution sur la machine hôte) peut se connecter. À ce moment-là, vous pouvez déboguer le programme dans GDB à peu près comme si vous étiez en cours d'exécution sur la machine hôte.

http://wiki.osdev.org/GDB semble avoir un peu plus d'informations de base; peut-être pas assez pour vous aider à démarrer complètement, mais au moins vous donner l'idée de base et quelques termes à rechercher dans la documentation QEMU et GDB. Passer sur le peu de « Mise en œuvre GDB Stubs », qui ne s'applique pas ici depuis QEMU a déjà un, et commencer à la section « Utilisation Emulator Stubs ». La forme courte est tout simplement que vous commencez QEMU avec l'option -s (exporter une connexion GDB sur localhost: 1234) et l'option -S (attendre une commande GDB « continue » avant l'exécution de départ), puis à GDB vous sur votre hôte dire target remote :1234 au lieu de run. En outre, bien sûr, vous devez utiliser une version ARM de GDB plutôt qu'un natif x86.

(En plus, si vous êtes prêt à payer pour une solution commerciale, ARM de toolchain de CodeSourcery a l'intégration IDE pour régler tout cela automatiquement, y compris le soutien pour « printf » pour imprimer dans la console de débogage. Cela fonctionne sur la une carte physique, aussi, si vous avez un débogueur matériel avertissement habituel sur moi être un employé CodeSourcery applique -.. mais je trouve qu'il est très facile à utiliser)

Mise à jour 2012: de toolchain de CodeSourcery est maintenant appelé Mentor Graphics Sourcery CodeBench, mais tout ce qui précède est toujours en vigueur

.

Autres conseils

Je me rends compte que je prends la parole devant votre problème original ici plutôt que la solution proposée (peut-être est mieux?), Mais d'utiliser GDB (ou Perspicacité / GDB) directement sur la cible, utilisez un outil JTAG à faible coût et OpenOCD . Un exemple d'un tel montage et comment la mettre en œuvre se trouve .

Si vous avez un budget plus important, un plus riche en fonctionnalités débogueur JTAG peut être utile, comme le Abatron BDI3000 avec bdiGDB firmware qui permet la programmation de débogage et le périphérique à distance sur Ethernet avec gDB et aucun pilote ou cible agent de débogage.

Peut-être un micronoyau comme OKL4 conviendrait à vos besoins?

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top