我遇到了QEMU不能从内存正确加载内核的问题。我已经在这个问题上卡了一天多了，我找不到问题的根源。
经过大量的调试和研究，我认为问题可能是与GDT。虽然，当我测试我的内核的最后一个工作版本时，当我包含多个头文件时，它也引发了同样的bug。
我的代码的REPO：https://github.com/lochyj/os
GDT.asm

gdt_start:
    dq 0x0          ; Base address of our segments

gdt_code:
    dw 0xffff       ; Segment length -> bits 0-15
    dw 0x0          ; Base address -> bits 0-15
    db 0x0          ; Base address -> bits 16-23
    db 10011010b    ; Flags -> 8 bits
    db 11001111b    ; Flags -> 4 bits + segment length -> bits 16-19
    db 0x0          ; Base address -> bits 24-31

gdt_data:
    dw 0xffff       ; Segment length -> bits 0-15
    dw 0x0          ; Base address -> bits 0-15
    db 0x0          ; Base address -> bits 16-23
    db 10010010b    ; Flags -> 8 bits
    db 11001111b    ; Flags -> 4 bits + segment length -> bits 16-19
    db 0x0          ; Base address -> bits 24-31

gdt_end:

gdt_descriptor:
    dw gdt_end - gdt_start - 1 ; Size of the gdt (16 bits)
    dd gdt_start    ; Address of the gdt (32 bits)

CODE_SEG equ gdt_code - gdt_start
DATA_SEG equ gdt_data - gdt_start

使用-d int运行img时，QEMU中的CPU转储部分

check_exception old: 0xffffffff new 0xd
     1: v=0d e=0032 i=0 cpl=0 IP=0008:0000efdb pc=0000efdb SP=0010:0008fff4 env->regs[R_EAX]=00000010
EAX=00000010 EBX=00007d63 ECX=00000000 EDX=00000200
ESI=00000000 EDI=00000000 EBP=00090000 ESP=0008fff4
EIP=0000efdb EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     00007ce6 00000017
IDT=     00000000 000003ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000010 CCD=00000010 CCO=ADDB
EFER=0000000000000000
check_exception old: 0xd new 0xd
     2: v=08 e=0000 i=0 cpl=0 IP=0008:0000efdb pc=0000efdb SP=0010:0008fff4 env->regs[R_EAX]=00000010
EAX=00000010 EBX=00007d63 ECX=00000000 EDX=00000200
ESI=00000000 EDI=00000000 EBP=00090000 ESP=0008fff4
EIP=0000efdb EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     00007ce6 00000017
IDT=     00000000 000003ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000010 CCD=00000010 CCO=ADDB
EFER=0000000000000000
check_exception old: 0x8 new 0xd

理论上内核应该能正常 Boot ，没有编译器或链接器错误，当我在vscode中使用十六进制编辑器比较时，工作的img文件和损坏的img文件之间似乎没有任何重大差异。工作和非工作版本中的引导装载程序是相同的，我看到了在两个版本中运行内核所需的所有数据，所以我不明白为什么它不能启动。
我在我的Windows10桌面上编译并运行了Arch for WSL的内核和引导加载程序。
我使用QEMU、GCC、NASM和LD来编译内核和引导加载程序。
任何意见都将受到欢迎。
我是操作系统开发的初学者，我还在学习。
先谢谢你。