La respuesta remota del paquete 'g' es demasiado larga

Question

Estoy intentando depurar kernel de Linux con kvm vm. Recibo 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. iniciar la máquina virtual con -kernel encargo, -initrd y opciones -append.
2. inicio GDB
3. Ejecutar "set arquitectura i386: x86-64: Intel"
4. Ejecutar "complemento de símbolos de archivos de Linux-3.0/vmlinux"
5. Ejecutar "mostrar arco" para verificar su todavía "i386 : x86-64: Intel"
6. ejecutar "localhost destino remoto: 1234"
7. ejecutar "continuar"
8. Presione Ctrl + C, me sale el mensaje anterior.

¿Alguien ha enfrentado este problema?

Answer 1

que también se enfrentó mismo tema, lo arreglé modificando gdbstub.c (en las fuentes de QEMU) para enviar registros de 64 bits siempre y dando a entender que la arquitectura es GDB 64 bits pasando set arch i386:x86-64

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

Answer 2

gdb no funciona bien contra una CPU que cambia entre los conjuntos de instrucciones en el tiempo de ejecución. Espere a que el kernel abandone el inicio anticipado antes de conectarse, y no use el indicador qemu -S.

Answer 3

Encontré un problema similar (& esta pregunta) conectando gdb muy temprano en el proceso de arranque - como se menciona en otras respuestas, gdb no aprecia mucho el tamaño de los registros que cambian de debajo. Este problema se puede ver mediante el uso de 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) 

Patching gdb to resize its internal buffer when it sees a too-large packet tal como se encuentra en este tema en el seguimiento de errores GDB (y otras partes), en efecto, evitar el problema, al igual que parchear QEMU sólo para enviar 64 bits paquetes de gran tamaño Sin embargo, the latter solution breaks debugging in non-64-bit-modes, y parece que la antigua solución podría ser incompleta:

Suena bastante mal estar cambiando el objetivo detrás de la espalda del BGF BGF cuando es ya depurarlo. 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 buscar/recalcular toda la descripción del objetivo . Hoy, creo que solo se puede hacer con un desconexión/reconexión.

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

La desconexión/conexión solución mencionada al final del post no parecen 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 4

que habían omitido accidentalmente el nombre binaria como argumento para GDB. Así que esto funcionó para mí.

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

Y luego tiene la Salida:

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

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