Удаленный ответ "g" слишком длинный

Ответ 1

gdb плохо работает с процессором, который переключается между наборами команд во время выполнения. Подождите, пока ядро ​​покинет раннюю загрузку перед подключением и не будет использовать флаг qemu -S.

Ответ 2

Я также столкнулся с той же проблемой, я исправил ее, изменив gdbstub.c(в источниках qemu), чтобы всегда отправлять 64-битные регистры и намекать на GDB, что архитектура имеет 64-битную передачу set arch i386:x86-64

Здесь вы можете проверить патч: Посетите [URL больше не доступно]

Ответ 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)

Патч gdb для изменения размера внутреннего буфера, когда он видит слишком большой пакет как обнаружено в этой проблеме в ggb-трекере ошибок (и в других местах), действительно обойти эту проблему, так же как и исправление 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
...

Ответ 4

Я случайно пропустил двоичное имя в качестве аргумента для gdb. Так что это сработало для меня.

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

И затем получил вывод:

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

Отладчику требуется vmlinux, поэтому убедитесь, что вы его предоставили. У OP есть другая проблема, но мой ответ может помочь тем, кто забыл предоставить аргумент gdb и получил то же сообщение об ошибке, что и OP.