X86: Modo protegido, GDT, IDT

Question

He intentado ejecutar el kernel simple con un cargador de arranque Kolibri. Se está cargando en 1000: 0000. No entiendo, ¿qué pasa en esta parte?

...
; switch to PM
mov eax, cr0
or  al, 1
mov cr0, eax

use32
PROTECTED_ENTRY:
mov  ax, 00010000b  ; DATA
mov  ds, ax
mov  ss, ax
mov  esp, 0xFFFF

jmp $

mov  ax, 00011000b  ; VIDEO
mov  es, ax
mov  edi, 0

mov  esi, string
int 1

jmp $

Porque en el depurador se parece a esto

¿Que está pasando aqui? ¿Por qué ES y DS no se están cambiando?

PD: Estoy tratando de hacer que este núcleo funcione con Kolibri Loader:http://wasm.ru/article.php?article=ia32int

Answer 1

El procesador no ingresa automáticamente al modo protegido cuando establece el bit protegido en cr0. Entra en modo protegido cuando cs se cambia después de eso. La forma más fácil de hacer esto es insertar un salto lejano inmediatamente después de escribir para cr0.

mov cr0, eax
.db 066h
jmp CODE_SEGMENT:PROTECTED_ENTRY

use32
PROTECTED_ENTRY:

Ojalá lo haya hecho bien. (Estoy acostumbrado a la sintaxis de AT&T). .db es una anulación del tamaño de operando para permitir una dirección de 32 bits.

Answer 2

Tee Debugger desmonta el código de 32 bits (usted le dijo al ensamblador que generara un código de 32 bits con el use32 Pseudo op) como código de 16 bits. Entonces la instrucción mov ax, 10h se interpreta como mov eax, d88e0010h, donde el d88e parte es en realidad el código de operación para la siguiente instrucción, mov ds,ax.

Similar para mov esp, 0xffff, que se interpreta como mov sp, 0xffff y los dos bytes cero adicionales aparecen como el espurio add byte ptr... instrucción.

Lo que realmente ejecuta el procesador depende de su estado actual: es en modo protegido, modo real, modo plano, etc. Mire los registros de estado para averiguarlo. Posiblemente pueda decirle al depurador que interprete el código diferente.