我正在尝试使用 kvm vm 调试 Linux 内核。我收到一条错误消息“远程‘g’数据包回复太长”。我的主机是 64 位的,我的虚拟机也是。
我的步骤:
有人遇到过这个问题吗?
gdb 不适用于在运行时在指令集之间切换的 cpu。在连接之前等待内核离开早期引导,并且不要使用 qemu 的
-S
标志。
我也遇到了同样的问题,我通过修改 gdbstub.c(在 qemu 源中)始终发送 64 位寄存器并通过传递
set arch i386:x86-64
提示 GDB 体系结构是 64 位来修复它
你可以在这里查看补丁: 访问 [URL 不再可用]
我在引导过程的早期就发现了连接 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 以在发现太大数据包时调整其内部缓冲区大小 正如在 gdb 错误跟踪器(和其他地方)中发现的这个问题一样,确实可以解决这个问题,就像修补 QEMU 以仅发送 64 位大小的数据包一样。然而,后一个解决方案破坏了非 64 位模式下的调试,而且似乎前一个修复可能不完整:
在后面改变目标听起来很不对 当 GDB already 调试它时,GDB 回来了。不仅仅是尺寸 g/G 数据包可能会无意中改变,但布局也是如此。 如果目标描述随着您的重新配置而改变,它 在我看来 GDB 应该获取/重新计算整个目标 描述。今天,我认为这只能通过 断开/重新连接。
帖子末尾提到的断开连接/重新连接解决方法似乎确实有效:
(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
...
我不小心省略了二进制名称作为 gdb 的参数。所以这对我有用。
$ gdb ./vmlinux
(gdb) target remote localhost:1234
然后得到输出:
Remote debugging using localhost:1234
0xffffffff81025f96 in default_idle ()
调试器需要 vmlinux 所以确保你提供它。 OP 有一个不同的问题,但我的回答可能会帮助那些忘记向 gdb 提供参数并最终得到与 OP 相同的错误消息的人。
用模拟器调试时 (gdb) 添加符号文件 此命令将无法正常工作,make (gdb) target remote localhost:xxxx 回复太长。它将与模拟器一起工作。
请改用此命令。成功了。参考 cdt-gdb-vscode。
(gdb) - 文件执行和符号