Estoy intentando usar GDB para depurar un kernel de Linux zImage antes de que se descomprima. El núcleo se está ejecutando en un destino ARM y tengo un depurador JTAG conectado a él con un código auxiliar del servidor GDB. El objetivo debe cargar un gestor de arranque. El gestor de arranque lee la imagen del núcleo desde el flash y la coloca en la RAM al 0x20008000, luego se bifurca a esa ubicación.Depurar etapa previa a la descompresión del kernel de Linux
he empezado BGF y conectado con el destino remoto, entonces yo uso de comandos de GDB add-symbol-file así:
add-symbol-file arch/arm/boot/compressed/vmlinux 0x20008000 -readnow
Cuando me puse un punto de interrupción para esa dirección, lo hace trampa en el lugar correcto - justo cuando se ramifica al kernel. Sin embargo, GDB muestra la línea incorrecta de la fuente de arch/arm/boot/compressed/head.S. Son 4 líneas detrás. ¿Cómo puedo arreglar esto?
También he intentado añadir la opción -s section addr-add-symbol-file con -s .start 0x20008000; esto da como resultado exactamente el mismo problema.
Primero asegúrese de tener un gcc y gdb que sean compatibles, preferiblemente de la misma versión de la cadena de herramientas. Además, sepa que el kernel de Linux está compilado con -O2, por lo que algunas líneas se optimizan. ¿Estás seguro de que no hay palabras clave .align en algún lugar? –
El código descompresor es todo relativo para PC. Incluso puede copiarse de una región a otra. El gestor de arranque puede colocarlo donde está el objetivo descomprimido; entonces tiene que moverse solo. Dudo que vayas a tener buenos momentos usando JTAG con símbolos fijos. No sé si puedes * reubicarte * con GDB de alguna manera. –