La réponse de paquet 'g' à distance est trop longue

Question

J'essaie de déboguer le noyau Linux avec kvm vm. Je reçois un message d'erreur "Remote 'g' réponse de paquet est trop longue". Mon hôte est 64 bits et ainsi est mon VM.

Mes pas:

1. Lancer la machine virtuelle avec -kernel personnalisé, des options et -initrd -append.
2. Démarrer gdb
3. Exécuter "set architecture i386: x86-64: intel"
4. Exécuter "add-symbole fichier linux-3.0/vmlinux"
5. Exécuter "arc show" pour vérifier son toujours « i386 : x86-64: intel »
6. Execute "cible à distance localhost: 1234"
7. Execute "continuer"
8. Appuyez sur Ctrl + C, je reçois le message ci-dessus.

Quelqu'un at-il fait face à ce problème?

Answer 1

J'ai aussi fait face à même question, je l'ai fixé en modifiant gdbstub.c (dans les sources de qemu) pour envoyer des registres 64bits toujours et laissant entendre GDB que l'architecture est 64bit en passant set arch i386:x86-64

Vous pouvez vérifier le patch ici: Visitez [URL n'est plus disponible]

Answer 2

gdb ne fonctionne pas bien avec un processeur qui bascule entre les jeux d'instructions au moment de l'exécution. Attendez que le noyau quitte le démarrage anticipé avant de se connecter, et n'utilisez pas le drapeau -S de qemu.

Answer 3

J'ai trouvé un problème similaire (& cette question) reliant gdb très tôt dans le processus de démarrage - comme mentionné dans d'autres réponses, gdb n'apprécie pas vraiment la taille des registres qui en sortent. Ce problème peut être vu à l'aide set debug remote 1:

(gdb) set debug remote 1 
(gdb) target remote localhost:1234 
Remote debugging using localhost:1234 
... 
Sending packet: $g#67...Ack 
Packet received: 000000000000000... <~600 bytes> 
(gdb) until *0x1000 # at this address we'll be in a different cpu mode 
... 
Sending packet: $g#67...Ack 
Packet received: 10000080000000000000000000000000800000c... <~1000 bytes> 
... 
Remote 'g' packet reply is too long: 1000008000000000000000000... 
(gdb) 

Patching gdb to resize its internal buffer when it sees a too-large packet que l'on trouve sur cette question dans le bug tracker gdb (et ailleurs), ne fonctionne en effet autour du problème, tout comme rapiéçage QEMU pour envoyer seulement 64 bits paquets -sized. Cependant, the latter solution breaks debugging in non-64-bit-modes, et il semble que l'ancienne solution pourrait être incomplète:

Il semble tout à fait tort de changer la cible derrière le dos de GDB quand GDB est déjà déboguer. Non seulement la taille des paquets g/G peut changer par inadvertance, mais la mise en page aussi bien. Si la description de la cible change avec votre reconfiguration, me semble que GDB devrait aller chercher/recalculer toute la description cible. Aujourd'hui, je pense que cela ne peut être fait avec un déconnecter/reconnecter.

- https://sourceware.org/ml/gdb/2014-02/msg00005.html

Le déconnexions/reconnexions solution de contournement mentionnée à la fin du poste ne semble fonctionner:

(gdb) disconnect 
Ending remote debugging. 
(gdb) set architecture i386:x86-64 
The target architecture is assumed to be i386:x86-64 
(gdb) target remote localhost:1234 
Remote debugging using localhost:1234 
(gdb) info registers 
rax   0x80000010 2147483664 
rbx   0x0 0 
... 

Answer 4

j'avais accidentellement omis le nom binaire comme argument pour gdb. Donc cela a fonctionné pour moi.

$ gdb ./vmlinux 
(gdb) target remote localhost:1234 

Et puis obtenu la sortie:

Remote debugging using localhost:1234 
0xffffffff81025f96 in default_idle() 

Le débogueur a besoin vmlinux faire en sorte que vous fournissez. OP a un problème différent, mais ma réponse pourrait aider ceux qui ont oublié de fournir des arguments à gdb et ont fini avec le même message d'erreur que OP.