我在引导过程的早期发现了一个类似的问题(&这个问题)连接 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 位大小的数据包一样. 但是,后一种解决方案会破坏 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
...