远程“g”数据包回复太长答案

【问题标题】：Remote 'g' packet reply is too long远程“g”数据包回复太长
【发布时间】：2012-01-29 13:16:35
【问题描述】：

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

我的步骤：

使用自定义 -kernel、-initrd 和 -append 选项启动 VM。
启动 gdb
执行“设置架构 i386:x86-64:intel”
执行“add-symbol-file linux-3.0/vmlinux”
执行“show arch”验证其仍然是“i386:x86-64:intel”
执行“目标远程本地主机：1234”
执行“继续”
按Ctrl+C，我得到了上面的信息。

有人遇到过这个问题吗？

【问题讨论】：

我的 vm 运行 ubuntu，主机运行 debian
如果我看到 gdb 代码，remote.c /* 远程协议寄存器的描述。 */ long sizeof_g_packet;与预期不符。看起来您的 gdbserver 配置不正确（不过我不太确定）。你在启动 GDB 服务器吗？如果是，您的 GDB 和 GDBSERVER 版本是否匹配？
在 GDB bugtracker 上类似：sourceware.org/bugzilla/show_bug.cgi?id=13984

标签： gdb linux-kernel kvm

【解决方案1】：

gdb 不适用于在运行时在指令集之间切换的 cpu。等待内核离开early boot后再连接，不要使用qemu的-S标志。

【讨论】：

删除 -S 选项后对我来说非常好
是的，但是如何？我需要在内核崩溃之前停止它；要在崩溃之前停止它，我需要gdb。如果我“等待”，内核就会崩溃。 :P
@Thanatos 我遇到了同样的问题，我将mov $0,%eax ; 0: ; test %eax,%eax ; jz 0b 放在源文件中并在崩溃前调用它。然后我附加调试器并执行set $eax = 1 并继续。可怕，但有效。

【解决方案2】：

我也遇到了同样的问题，我通过修改 gdbstub.c（在 qemu 源代码中）来修复它以始终发送 64 位寄存器并通过传递 set arch i386:x86-64 提示 GDB 架构是 64 位

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

【讨论】：

我不必修补 QEMU - 只需告诉 GDB set arch i386:x86-64 就足够了。
总是发送 x86-64 寄存器会完全破坏实模式调试。不能正确拆解，step over(next)也不能正常工作，同step.我今天尝试调试一个 SMP 蹦床（实模式部分），这是不可能的，step 对线程 2 没有影响。不幸的是，这个答案中提到的 hack 已被采用到 qemu 代码中。真正的问题是 gdb，但当寄存器文件改变大小时，它完全被破坏了。如果你问我，GDB 甚至不支持 x86。

【解决方案3】：

我在引导过程的早期发现了一个类似的问题（&这个问题）连接 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)

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

【讨论】：

我又得到了同样的Remote 'g' packet is too long' immediately after running target remote localhost:1234`。
@Thanatos 它对我有用。这是我的详细设置：stackoverflow.com/questions/4943857/…

【解决方案4】：

我不小心遗漏了二进制名称作为 gdb 的参数。所以这对我有用。

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

然后得到输出：

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

调试器需要 vmlinux，因此请确保提供它。 OP 有一个不同的问题，但我的回答可能对那些忘记向 gdb 提供参数并最终得到与 OP 相同的错误消息的人有所帮助。

【讨论】：