Я обнаружил похожую проблему (и этот вопрос) при подключении 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 возвращается, когда 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
...