Estoy fuera del ejecutable de destino de gdb y ni siquiera tengo una pila que corresponda a ese objetivo. Quiero un solo paso de todos modos, 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 hacer esta simple depuración a nivel de ensamblado. Me permite establecer y detener el punto de interrupción apropiado, pero tan pronto como trato de 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 núcleo donde se está ejecutando, desde la salida de objdump -d. No me importaría una manera simple de usar un cargador para cargar mi código de objeto en una dirección reubicada, pero tenga en cuenta que la carga debe hacerse en un módulo del núcleo.

Supongo que otra alternativa sería producir un módulo de kernel falso o un archivo de información de depuración para dar a gdb, para que crea que esta área está dentro del código del programa. gdb funciona bien en el ejecutable del kernel mismo.

(Para aquellos que realmente quieran saber, estoy insertando el código en tiempo de ejecución en el espacio de datos del kernel de Linux dentro de una VM VMware y depurándolo desde gdb depuración remota del kernel a través del stub gdb incorporado de VMware Workstation. Tenga en cuenta que no estoy escribiendo kernel exploits; soy un estudiante graduado de seguridad 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).