¿Cómo usar kgdb en ARM?

linux-kernel

Question

Estoy usando ARMv7 como una máquina de destino. He compilado la fuente de Linux 2.6.34.13 para el objetivo.

Target está conectado con Host (máquina de desarrollo de Linux) a través del puerto serie utilizando minicom.

El objetivo se carga con un kernel nuevo y KGDB se habilita en el símbolo del sistema.

$ echo ttyAMA0 > /sys/module/kgdboc/parameters/kgdboc
$ echo g > /proc/sysrq-trigger

Se muestra el mensaje KGDB ... entrante y espera los comandos.

En el lado Host ,

$arm-none-linux-gnueabi-gdb vmlinux
gdb > set remotebaud 115200
gdb > set debug remote 1
gdb > target remote /dev/ttyS0

Después de esto, algunas comunicaciones de comando tienen lugar por defecto.

1. qSupported se envía de Host a Target. Pero qSuppoted no es compatible con el objetivo, por lo que se devuelve $ # 00. similarmente ? , Se enviaron comandos HC-1 pero recibe la respuesta adecuada.

2. Pero el comando qOffsets no recibe ninguna respuesta del objetivo.

Sospecho que vmlinux. Porque si doy la list en gdb, no muestra 10 líneas de código, sino que dice

arch/arm/kernel/head.S : No such file or directory.

Nota :: La compilación del kernel se realiza en el servidor. por lo tanto, no hay fuente disponible en la máquina de desarrollo. Pero arm-gdb busca la cabeza. Parece.

No estoy seguro de qué error estoy haciendo. Necesito símbolos para cargar todo el núcleo. Guíame en este sentido.

Answer 1

Ese kgdb está buscando head.S no es un error. Si miras aquí , verás que hay un archivo head.S en el árbol de fuentes. Es un archivo ensamblador, eso es todo. Hay varios archivos fuente escritos en ensamblador para esta plataforma.

Es normal, porque algunas instrucciones, especialmente las secuencias de inicio y otras funcionalidades de "bajo nivel", se escriben en ensamblador porque es más fácil.

Como ya se ha escrito en los comentarios, gdb necesita las fuentes para examinarlos durante la depuración. En las secciones de depuración, que contienen los símbolos de depuración y se generan cuando se ejecuta gcc con -g , hay "solo" referencias al archivo fuente y línea y columna, entre otros. Consulte aquí para obtener más información y más enlaces sobre los símbolos de depuración con gcc.

Ese kgdb está buscando head.S Es una buena señal de que estás haciendo las cosas bien. Si tiene las fuentes disponibles (y puede ser tan simple como desmarcar el tarball de la versión correcta) simplemente ejecute kgdb dentro de este árbol fuente o use el argumento -d para agregar source-search-path, estando en su máquina de desarrollo de curso.

Answer 2

Finalmente, la comunicación de Host to Target estableció solo bcos of line delay. No existe una relación entre el origen del núcleo en la máquina de desarrollo y los problemas de tiempo de espera.

Para el tipo de problema de tiempo de espera para algunos de los comandos, diga qOffset y qSupported se resuelve utilizando GtkTerm en lugar de minicom como la herramienta de comunicación del puerto serie. La diferencia es la opción de "retardo de línea" en GtkTerm. así que cuando esto está configurado a ~ 250, no hay mensaje de tiempo de espera a partir de entonces. simplemente se establece la conexión y espera en el punto de ruptura predeterminado. Si alguien sabe cómo dar este "line delay" en minicom será más útil para todos.

sí, por supuesto, necesitamos el código fuente para el comando de list para ejecutar. pero sin esa fuente también, podemos depurar, es decir si, bt se puede ejecutar con la ayuda de vmlinux y system.map .

Note :: set debug remote 1 no es necesario. Esto proporciona una visualización detallada de las comunicaciones de comando del host. Para una vista más detallada, set debug serial 1 .