远程'g‘数据包回复太长了
我正在尝试用kvm调试Linux内核。我收到一条错误信息“远程'g‘数据包回复太长”。我的主机是64位，我的vm也是。
我的脚步：
- 使用自定义的-kernel、-initrd和-append选项启动VM。
- 启动gdb
- 执行"set architecture i 386:x86-64:intel“
- 执行“add-符号-file linux-3.0/vmlinux”
- 执行“显示拱”以验证其仍然“i 386:x86-64:intel”。
- 执行“目标远程本地主机:1234”
- 执行“继续”
- 按Ctrl+C键，我收到上面的消息。
有人面临过这个问题吗？
回答 4
Stack Overflow用户
发布于 2013-05-09 11:33:56
对于在运行时在指令集之间切换的cpu，gdb不能很好地工作。等待内核在连接之前离开早期引导，并且不要使用qemu的-S标志。
Stack Overflow用户
发布于 2012-02-06 04:12:37
我也面临着同样的问题，我通过修改gdbump.c(在qemu源代码中)始终发送64位寄存器来修正它，并通过传递set arch i386:x86-64来暗示GDB是64位
您可以在这里查看修补程序:访问不再可用的URL
Stack Overflow用户
发布于 2015-12-16 04:49:54
在启动过程的早期，我发现了一个类似的问题(&这个问题)连接gdb --正如其他答案中提到的，gdb并不十分了解从它下面变化的寄存器的大小。使用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)在gdb bug跟踪器(和其他地方)中发现的当gdb看到太大的数据包时，修补gdb以调整其内部缓冲区的大小。确实解决了这个问题，修补QEMU只发送64位大小的数据包。然而，后一种解决方案在非64位模式下中断调试。，而且似乎前者的修复可能是不完整的：
当GDB已经在调试目标时，在GDB背后更改目标听起来是非常错误的。不仅g/G数据包的大小可能会在不经意间发生变化，而且布局也会发生变化。如果目标描述随着重新配置而发生变化，在我看来，GDB应该获取/重新计算整个目标描述。今天，我认为这只能通过断开/重新连接来完成。 - https://sourceware.org/ml/gdb/2014-02/msg00005.html
文章末尾提到的断开/重新连接解决方案看起来确实有效：
(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
...https://stackoverflow.com/questions/8662468
复制相似问题
腾讯云开发者
