远程'g'数据包回复太长

Question

我正在尝试使用kvm vm调试Linux内核。我收到错误消息“远程'g'数据包回复太长”。我的主机是64位，我的虚拟机也是。

我的步骤：

1. 使用自定义-kernel，-initrd和-append选项启动VM。
2. 启动gdb
3. 执行“set architecture i386：x86-64：intel”
4. 执行“add-symbol-file linux-3.0 / vmlinux”
5. 执行“show arch”以验证其仍为“i386：x86-64：intel”
6. 执行“target remote localhost：1234”
7. 执行“继续”
8. 按Ctrl + C，我收到上述消息。

有人遇到过这个问题吗？

Answer 1

gdb对于在运行时在指令集之间切换的cpu不能很好地工作。在连接之前等待内核保持早期启动，并且不要使用qemu的-S标志。

Answer 2

我也面临同样的问题，我通过修改gdbstub.c（在qemu源代码中）来修复它，总是发送64位寄存器并通过传递set arch i386:x86-64

来暗示GDB架构为64位

您可以在此处查看补丁： 访问[URL不再可用]

Answer 3

我发现在启动过程中很早就连接了gdb的类似问题（＆amp; this question） - 正如其他答案中所提到的，gdb并不太了解从它下面更改的寄存器的大小。使用<input type="tel" /> ：

可以看到此问题

set debug remote 1

Patching gdb to resize its internal buffer when it sees a too-large packet 正如在gdb错误跟踪器（以及其他地方）中发现的那样，确实可以解决问题，将QEMU修补为仅发送64位大小的数据包。但是，the latter solution breaks debugging in non-64-bit-modes，似乎前一个修复可能不完整：

  

改变背后的目标听起来是错误的   当GDB 已经调试它时，GDB回来了。不只是尺寸   g / G数据包的数据可能会无意中发生变化，但布局也是如此。   如果目标描述随您的重新配置而变化，则为   听起来像GDB应该获取/重新计算整个目标   描述。今天，我认为这只能用一个   断开/重新连接。

     

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

帖子末尾提到的断开/重新连接解决方​​法确实有效：

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