3

我正在使用FASM（平面汇编程序）编写引导加载程序。我在 16 位模式下成功，但在切换到 32 位模式时遇到错误。我查看了一个类似的答案（实际上在跳到保护模式后在 GPF 出现了同样的问题），但该解决方案并没有解决我的问题。

这是我的引导加载程序 -

org 0x7c00

jmp main

include 'bios.asm'
include 'print32.asm'
include 'gdt.asm'

main:

mov bp,0x9000
mov sp,bp

mov bx, bootMsg
call print_string

lgdt [gdt_descriptor]
cli
mov eax, cr0
or eax, 0x1
mov cr0, eax
jmp CODE_SEG:init_pm   ;**The error seems to occurs here

jmp $

bits = 32

init_pm:
    mov ax,DATA_SEG
    mov ds,ax
    mov ss,ax
    mov es,ax

    mov ebp, 0x90000
    mov esp, ebp
    jmp BEGIN_PM

BEGIN_PM:
    mov ebx, pmMsg
    call print_string32
    jmp $

pmMsg:
    db "Sucessfully switched to the 32-bit protected mode....",0

bootMsg:
    db "Booted in 16-bit Real Mode mode....",0

times 510-($-$$) db 0
dw 0xaa55

这是 GDT -

gdt_start:
gdt_null:
    dd 0x0
    dd 0x0

gdt_code:
    dw 0xffff
    dw 0x0
    db 0x0
    db 10011010b
    db 11001111b
    db 0x0

gdt_data:
    dw 0xffff
    dw 0x0
    db 0x0
    db 10010010b
    db 11001111b
    db 0x0
gdt_end:

gdt_descriptor:
    dw gdt_end - gdt_start - 1
    dd gdt_start

CODE_SEG equ gdt_code - gdt_start
DATA_SEG equ gdt_data - gdt_start

她是 Bochs 控制台输出 -

00478171069i[BIOS  ] Booting from 0000:7c00
00478195765e[CPU0  ] write_virtual_checks(): write beyond limit, r/w
00478195765e[CPU0  ] interrupt(): gate descriptor is not valid sys seg (vector=0x0d)
00478195765e[CPU0  ] interrupt(): gate descriptor is not valid sys seg (vector=0x08)
00478195765i[CPU0  ] CPU is in protected mode (active)
00478195765i[CPU0  ] CS.mode = 32 bit
00478195765i[CPU0  ] SS.mode = 32 bit
00478195765i[CPU0  ] EFER   = 0x00000000
00478195765i[CPU0  ] | EAX=d88e0010  EBX=00007d77  ECX=00090000  EDX=00000000
00478195765i[CPU0  ] | ESP=00009000  EBP=00000000  ESI=000e0000  EDI=0000ffac
00478195765i[CPU0  ] | IOPL=0 id vip vif ac vm RF nt of df if tf sf zf af PF cf
00478195765i[CPU0  ] | SEG sltr(index|ti|rpl)     base    limit G D
00478195765i[CPU0  ] |  CS:0008( 0001| 0|  0) 00000000 ffffffff 1 1
00478195765i[CPU0  ] |  DS:0000( 0005| 0|  0) 00000000 0000ffff 0 0
00478195765i[CPU0  ] |  SS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00478195765i[CPU0  ] |  ES:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00478195765i[CPU0  ] |  FS:0000( 0005| 0|  0) 00000000 0000ffff 0 0
00478195765i[CPU0  ] |  GS:0000( 0005| 0|  0) 00000000 0000ffff 0 0
00478195765i[CPU0  ] | EIP=00007d2f (00007d2f)
00478195765i[CPU0  ] | CR0=0x60000011 CR2=0x00000000
00478195765i[CPU0  ] | CR3=0x00000000 CR4=0x00000000
00478195765i[CPU0  ] 0x0000000000007d2f>> or dword ptr ds:[eax], eax : 0900
00478195765e[CPU0  ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting

谁能帮我解决这个问题？这个问题困扰我很久了。。

编辑-

这是 print32 代码-

use32

VIDEO_MEM equ 0xb8000
W_O_B equ 0x0f

print_string32:
    pusha
    mov edx,VIDEO_MEM

print_string32_loop:
    mov al, [ebx]
    mov ah, W_O_B
    cmp al,0
    je print_string32_end
    mov [edx],ax
    inc ebx
    add edx,2
    jmp print_string32_loop

print_string32_end:
    popa
    ret

以及引导加载程序的更改代码 -

org 0x7c00

mov bp,0x9000
mov sp,bp

mov bx, bootMsg
call print_string

cli
lgdt [gdt_descriptor]
mov eax, cr0
or eax, 0x1
mov cr0, eax
jmp 0x8:init_pm

jmp $

use32

init_pm:
    mov ax, 0x10
    mov ds, ax
    mov ss, ax
    mov es, ax
    mov fs, ax
    mov gs, ax

    mov ebp,0x90000
    mov esp,0x90000

    jmp BEGIN_PM

jmp $

include 'bios.asm'
include 'gdt.asm'
include 'print32.asm'

use32

BEGIN_PM:
    mov ebx, pmMsg
    call print_string32
    jmp $

pmMsg:
    db "Sucessfully switched to the 32-bit protected mode....",0

bootMsg:
    db "Booted in 16-bit Real Mode mode....",0

times 510-($-$$) db 0
dw 0xaa55
4

1 回答 1

3

TL;DR：修复更改bits = 32为use32

让FASM为在 32 位模式下运行的处理器生成指令。FASM 文档在第1.1.4 节输出格式中指出：

默认情况下，当源文件中没有格式指令时，平面汇编器只是将生成的指令代码放入输出中，这样就创建了平面二进制文件。默认情况下，它生成16 位代码，但您始终可以使用 use16 或use32指令将其转换为 16 位或32 位模式。

似乎您bits = 32在将NASM代码转换为FASM时使用过，并且bits 32未被FASM接受。bits=32设置一个名为bits32 的常量值。它不会告诉FASM生成指令以供 32 位模式下的处理器使用。尽管bits = 32组装没有错误，但它并没有达到您的预期。

通过不使用use32您告诉FASM在使用 32 位地址和在 16 位实模式下工作的操作数的指令之后生成代码init_pm，而不是使用在 32 位保护模式下工作的 32 位地址和操作数的指令。

尽管我无法测试您的代码，但我将在尝试了解您发布的代码可能发生的情况时进行这些观察。首先，BOCHS转储这些行：

[CPU0  ] 0x0000000000007d2f>> or dword ptr ds:[eax], eax : 0900
[CPU0  ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting

这表示在地址 0x7d2for dword ptr ds:[eax], eax遇到指令（其编码为 0900）并生成异常 13（一般保护错误）。

当时BOCHS状态转储中有一些内容表明您处于保护模式：

CPU is in protected mode (active)

此外，还有一个正确执行的指示jmp CODE_SEG:init_pm。这是因为在您的错误BOCHS转储时CS:0008这意味着CS设置为值 0008 (= CODE_SEG)。DS选择器为 0，这是不寻常的，因为在JMP之后您将其设置为 DATA_SEG (0x10) 但ES和SS段选择器设置为 0x10。这一切都表明init_pm代码已执行，但不知何故最终没有按预期执行。

此时我意识到您已经编写bits = 32了有效地将常量设置为值 32。它不会告诉FASM生成将针对将在 32 位模式下执行的 CPU 的代码。

考虑到这一点，我决定接受这些指令并让汇编器将它们编码为 16 位模式：

init_pm:
    mov ax,DATA_SEG
    mov ds,ax
    mov ss,ax
    mov es,ax

    mov ebp, 0x90000

当我使用 NDISASM 选项（强制 NDISASM 解码为 32 位目标）转储测试代码时，它将-b32其解码为：

00000000  B810008ED8        mov eax,0xd88e0010
00000005  8ED0              mov ss,eax
00000007  8EC0              mov es,eax
00000009  66BD0000          mov bp,0x0
0000000D  0900              or [eax],eax
0000000F  6689EC            mov sp,bp

不正确的解码首先做了mov eax, 0xd88e0010。这解释了为什么在您的BOCHS转储中您有EAX=d88e0010 . EAX的低 16 位已移至ES，因此 ES=0x0010 与您的BOCHS输出匹配ES:0010。类似的事情适用于SS被设置。BP设置为 0，这在BOCHS输出中得到确认BP:0000。该指令导致故障和崩溃：

0000000D  0900              or [eax],eax

or [eax],eax是一样的or ds:[eax],eax。[eax]隐含对DS的引用。将此指令与BOCHS输出进行比较：

0x0000000000007d2f>> or dword ptr ds:[eax], eax : 0900

啊哈，这就是这个不寻常的指令的来源（你可以忽略DWORD PTR）。错误解码的指令尝试使用指向 NULL (0x0000) 描述符的DS 。这会导致处理器故障，以及BOCHS和状态转储报告的后续错误。

正如我在评论中所说，在BOCHS中使用内部调试器很有价值，尤其是在调试引导加载程序和内核时。如果您在调试器中一次执行一个引导加载程序指令，您可能会发现您的FAR JMP可以init_pm按预期工作。然后您会观察到正在执行的意外指令最终导致处理器故障。

于 2016-09-19T17:18:17.190 回答