CODEWITHSUNDEEP
gdblinux-kernelkvm
contemplatingzombie
contemplatingzombie

Reputation: 263

Remote 'g' packet reply is too long

I am trying to debug Linux kernel with kvm vm. I am getting an error message "Remote 'g' packet reply is too long". My host is 64-bit and so is my vm.

My steps:

  1. Start the VM with custom -kernel, -initrd and -append options.
  2. Start gdb
  3. Execute "set architecture i386:x86-64:intel"
  4. Execute "add-symbol-file linux-3.0/vmlinux"
  5. Execute "show arch" to verify its still "i386:x86-64:intel"
  6. Execute "target remote localhost:1234"
  7. Execute "continue"
  8. Press Ctrl+C, I get the above message.

Has anyone faced this problem?

Upvotes: 22

Views: 28763

Answers (5)

Samir Das
Samir Das

Reputation: 121

I also faced same issue, I fixed it by modifying gdbstub.c (in qemu sources) to send 64bit registers always and hinting GDB that architecture is 64bit by passing set arch i386:x86-64

Upvotes: 11

Hoàng Quân Nguyễn Bá
Hoàng Quân Nguyễn Bá

Reputation: 1

when debug with simulator (gdb) add-symbol-file this command will not work correctly, make (gdb) target remote localhost:xxxx reply is too long. It will work with simulator.

use this command instead. It's worked. Refer cdt-gdb-vscode.

(gdb) -file-exec-and-symbol

Upvotes: 0

SloppyJoe
SloppyJoe

Reputation: 403

I had accidentally omitted the binary name as an argument to gdb. So this worked for me.

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

And then got the Output :

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

The debugger needs vmlinux so make sure you provide it. OP has a different problem, But my answer might help to those who forgot to provide argument to gdb and ended up with the same error message as OP.

Upvotes: 2

Seth P
Seth P

Reputation: 463

I found a similar problem (& this question) connecting gdb very early in the boot process – as mentioned in other answers, gdb does not very much appreciate the size of registers changing out from under it. This problem can be seen by using 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 as found on this issue in the gdb bug tracker (and elsewhere), does indeed work around the problem, as does patching QEMU to only send 64-bit-sized packets. However, the latter solution breaks debugging in non-64-bit-modes, and it seems that the former fix could be incomplete:

It sounds quite wrong to be changing the target behind GDB's back when GDB is already debugging it. Not just the size of the g/G packets may change inadvertently, but the layout as well. If the target description changes with your re-configuration, it sounds to me like GDB should fetch/recompute the whole target description. Today, I think that can only be done with a disconnect/reconnect.

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

The disconnect/reconnect workaround mentioned at the end of the post does appear to work:

(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
...

Upvotes: 8

Gabriel
Gabriel

Reputation: 1322

gdb doesn't work well against a cpu that switches between instruction sets at runtime. Wait for the kernel to leave early boot before connecting, and don't use qemu's -S flag.

Upvotes: 15

Related Questions