Estoy fuera del ejecutable de destino de gdb y ni siquiera tengo una pila que corresponda a ese destino. De todos modos, quiero dar un solo paso, para poder verificar lo que está sucediendo en mi código de ensamblaje, porque no soy un experto en ensamblaje x86. Desafortunadamente, gdb se niega a realizar esta sencilla depuración a nivel de ensamblador. Me permite establecer y detenerme en el punto de interrupción apropiado, pero tan pronto como intento avanzar en un solo paso, gdb informa el error "No se pueden encontrar los límites de la función actual" y el EIP no cambia.
Detalles adicionales:
El código de la máquina fue generado por las declaraciones gcc asm y lo copié en la ubicación de la memoria del kernel donde se está ejecutando, desde la salida de objdump -d. No me importaría una forma sencilla de usar un cargador para cargar mi código objeto en una dirección reubicada, pero tenga en cuenta que la carga debe realizarse en un módulo del kernel.
Supongo que otra alternativa sería producir un módulo de kernel falso o un archivo de información de depuración para entregarlo a gdb, para que crea que esta área está dentro del código del programa. gdb funciona bien en el propio ejecutable del kernel.
(Para aquellos que realmente quieran saber, estoy insertando código en tiempo de ejecución en el espacio de datos del kernel de Linux dentro de una VM de VMware y depurándolo desde gdb depurando el kernel de forma remota a través del código auxiliar de gdb integrado de VMware Workstation. Tenga en cuenta que no estoy escribiendo kernel exploits; soy un estudiante de posgrado en seguridad que está escribiendo un prototipo).
(Puedo establecer un punto de interrupción en cada instrucción dentro de mi ensamblaje. Esto funciona pero se volvería bastante laborioso después de un tiempo, ya que el tamaño de las instrucciones de ensamblaje x86 varía y la ubicación del ensamblaje cambiará cada vez que reinicie).