Ответ удаленного пакета 'g' слишком длинный - PullRequest
Новая
       12

Ответ удаленного пакета 'g' слишком длинный

19 голосов
/ 29 декабря 2011

Я пытаюсь отладить ядро ​​Linux с помощью kvm vm. Я получаю сообщение об ошибке «Удаленный ответ пакета« g »слишком длинный». Мой хост 64-битный и мой vm.

Мои шаги:

  1. Запустите виртуальную машину с опциями -kernel, -initrd и -append.
  2. Start GDB
  3. Выполнить "установить архитектуру i386: x86-64: intel"
  4. Выполнить «add-symbol-file linux-3.0 / vmlinux»
  5. Выполните «show arch», чтобы проверить его неподвижность «i386: x86-64: intel»
  6. Выполнить "целевой удаленный локальный хост: 1234"
  7. Выполнить «продолжить»
  8. Нажмите Ctrl + C, я получу сообщение выше.

Кто-нибудь сталкивался с этой проблемой?

Ответы [ 4 ]

12 голосов
/ 09 мая 2013

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

8 голосов
/ 06 февраля 2012

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

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

6 голосов
/ 16 декабря 2015

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

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

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

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

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

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

...