gdb - La respuesta del paquete ''g'' remoto es demasiado larga

linux-kernel kvm

Question

Estoy intentando depurar el kernel de Linux con kvm vm. Aparece un mensaje de error "La respuesta del paquete ''g'' remoto es demasiado larga". Mi host es de 64 bits y también lo es mi vm.

Mis pasos

1. Inicie la máquina virtual con las opciones personalizadas de kernel, -initrd y -append.
2. Iniciar gdb
3. Ejecute "set architecture i386: x86-64: intel"
4. Ejecute "add-symbol-file linux-3.0 / vmlinux"
5. Ejecute "show arch" para verificar que esté "i386: x86-64: intel"
6. Ejecutar "localhost remoto objetivo: 1234"
7. Ejecutar "continuar"
8. Presiona Ctrl + C, me sale el mensaje de arriba.

Alguien ha enfrentado este problema?

Answer 1

Accidentalmente había omitido el nombre binario como un argumento para gdb. Así que esto funcionó para mí.

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

Y luego consiguió la salida:

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

El depurador necesita vmlinux, así que asegúrese de proporcionarlo. OP tiene un problema diferente, pero mi respuesta podría ayudar a quienes olvidaron proporcionar un argumento a gdb y terminaron con el mismo mensaje de error que OP.

Answer 2

Encontré un problema similar (y esta pregunta) al conectar gdb muy temprano en el proceso de arranque. Como se mencionó en otras respuestas, gdb no aprecia mucho el tamaño de los registros que se están modificando. Este problema se puede ver usando 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)

La aplicación de parches a gdb para cambiar el tamaño de su búfer interno cuando ve un paquete demasiado grande como se encuentra en este problema en el rastreador de errores de gdb (y en otros lugares), efectivamente soluciona el problema, al igual que la aplicación de parches a QEMU para enviar solo paquetes de 64 bits. . Sin embargo, la última solución rompe la depuración en modos que no son de 64 bits , y parece que la solución anterior podría estar incompleta:

Suena bastante mal cambiar el objetivo detrás de la espalda de GDB cuando GDB ya lo está depurando. No solo el tamaño de los paquetes g / G puede cambiar inadvertidamente, sino también el diseño. Si la descripción del objetivo cambia con su reconfiguración, me parece que GDB debería recuperar / volver a calcular la descripción del objetivo completo. Hoy, creo que solo se puede hacer con una desconexión / reconexión.

- https://sourceware.org/ml/gdb/2014-02/msg00005.html

La solución de desconexión / reconexión mencionada al final de la publicación parece funcionar:

(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
...

Answer 3

También tuve el mismo problema, lo arreglé modificando gdbstub.c (en fuentes qemu) para enviar registros de 64 bits siempre e insinuando a GDB que la arquitectura es de 64 bits al pasar set arch i386:x86-64

Puede consultar el parche aquí: Visite [URL ya no está disponible]

Answer 4

gdb no funciona bien contra una CPU que cambia entre conjuntos de instrucciones en tiempo de ejecución. Espere a que el kernel deje el inicio temprano antes de conectarse, y no use el distintivo -S de qemu''s.