bootloader执行lgdt加载全局描述符表触发CPU报错问题排查

lgdt指令本身仅会将指定内存中的6字节数据加载到GDTR寄存器，不会做GDT内容合法性校验，你遇到的三重故障（QEMU反复重启闪屏）是后续指令访问无效GDT描述符、栈结构被破坏导致的，核心硬错误有三个：

• GDT段描述符的flags字段写错，生成了无效段描述符
  你在代码段、数据段中定义flags+段限长高4位的字节时，写的是db 0100111b，这是一个7位二进制值，汇编器会自动在最高位补0，最终得到的字节值是0x27（二进制00100111），和你预期的配置完全不符：
  • 该字节最高位（G粒度位）为0：段限长单位为1字节而非4KB
  • 次高位（D/B 32位标志位）为0：CPU会将段识别为16位段
  • 第三位（L长模式位）为1：32位保护模式下不允许代码段设置该位，属于无效描述符
  • 低4位段限长为0111b而非你预期的1111b，最终段限长仅为512KB，无法覆盖4GB平坦地址空间
    正确配置应为db 11001111b（即0xCF）：高4位1100对应G=1（4KB粒度）、D=1（32位段）、L=0（非长模式）、AVL=0，低4位1111配合低16位限长0xFFFF，在4KB粒度下正好覆盖4GB线性地址空间。
• GDTR中存储的GDT基地址不是物理线性地址
  GDTR要求存储的GDT基地址是线性物理地址，但你写的dd gdt_start只会被汇编器替换为符号相对于程序起始位置的偏移。BIOS默认将bootloader加载到物理地址0x7C00处，如果你没有在汇编开头声明org 0x7C00，或者执行lgdt时DS段寄存器不为0，CPU实际读取GDT的地址完全错误，会读到垃圾数据作为段描述符。
  可以通过两种方式修复：
  1. 汇编文件最开头添加org 0x7C00，同时保证执行到switch32时DS=0，让所有符号地址直接对应物理地址
  2. 加载GDTR前手动计算GDT物理地址，参考代码：

     xor eax, eax
     mov ax, ds
     shl eax, 4       ; 实模式段地址转线性地址基址：段值*16
     add eax, gdt_start
     mov [gdtr_data + 2], eax ; 写入GDTR的基地址字段
     

• 16位/32位栈操作不匹配，直接破坏栈结构触发三重故障
  你在16位实模式下执行pusha，该指令在16位模式下会压入8个16位通用寄存器，共占16字节栈空间；但切到32位保护模式后执行的popa是32位指令，会弹出8个32位寄存器共32字节，直接读穿栈帧破坏数据。
  更严重的是，你是用16位call指令调用的switch32，栈上仅压入了2字节的16位返回地址，而32位模式下的ret指令会从栈上弹出4字节作为返回地址，执行后会直接跳转到随机地址，触发CPU三重故障导致系统重启，这就是QEMU屏幕闪烁的直接原因。
  修复方式：不要用16位的call/ret、pusha/popa逻辑跨模式调用，切换到保护模式后先初始化32位栈，再通过远跳直接进入32位入口点，不要尝试从32位代码ret回16位上下文（除非你手动做了模式切换返回的兼容处理）。

额外注意事项 #

• 切换到保护模式后，在完成32位IDT设置前不要开启中断，你当前的cli仅屏蔽了可屏蔽中断，未处理IDT无效的问题，一旦有中断触发会直接进入故障处理流程。
• 远跳刷新流水线的指令要确保是16位模式下编码的远跳转，如果你在[bits 32]之后写远跳指令，汇编器会生成32位编码的指令，CPU在16位模式下预取时会解码错误。

内容的提问来源于stack exchange，提问作者MottLx