OS开发：添加GDT时遭遇GDB调试异常问题求助

你遇到的GDB调试异常行为，核心是两个关键问题叠加导致的：16位实模式下执行32位保护模式代码，以及内核加载地址与链接地址不匹配，下面分步拆解并给出解决方案：

一、核心问题定位 #

1. 模式不匹配导致指令解析错误
   你的bootloader运行在16位实模式，但编译出的内核是32位保护模式代码。CPU在16位模式下会把32位指令错误解码成16位指令执行，直接导致执行流程完全混乱——这就是为什么si命令无法正确进入main，反而出现奇怪跳转的根本原因。

2. 加载地址与链接地址错位
   bootloader把内核加载到物理地址0x1000（es=0x100，bx=0，即0x100*16+0=0x1000），但kernel.lds里指定.text段从0x2000开始。链接器生成的所有内核符号（比如_start、main）都是基于0x2000的地址，实际执行时地址错位，函数调用自然会失败。

二、分步解决方案 #

1. 修正内核加载地址与链接地址匹配 #

让内核的加载地址和链接脚本指定的地址完全一致：

• 修改bootloader.asm中的加载目标地址：

  ; 原来的mov ax, 0x100改成0x200，对应物理地址0x2000
  mov ax, 0x200
  mov es, ax
  xor bx, bx
  

• 跳转指令保持jmp [0x2000 + 0x18]即可——这是读取ELF头中偏移0x18处的入口点地址（从readelf输出看是0x2140），对应加载到0x2000后的正确物理地址。

2. 添加实模式到32位保护模式的切换代码 #

32位内核必须在保护模式下执行，需要在bootloader中完成模式切换：

bits 16
start:
    jmp boot

;; 常量定义
welcome_msg db "Welcome to NyanOS!", 0ah, 0dh, 0h
err_msg db "E", 0h

; 定义最简GDT（空描述符+32位代码段+32位数据段）
gdt_start:
    dd 0x0 ; 空描述符
    dd 0x0
gdt_code: ; 32位代码段：基址0，限长4GB，可执行可读
    dw 0xffff
    dw 0x0
    db 0x0
    db 0b10011010 ; 存在位=1，特权级0，代码段，可执行，可读
    db 0b11001111 ; 粒度=4KB，32位模式，限长高4位
    db 0x0
gdt_data: ; 32位数据段：基址0，限长4GB，可读写
    dw 0xffff
    dw 0x0
    db 0x0
    db 0b10010010 ; 存在位=1，特权级0，数据段，可写
    db 0b11001111
    db 0x0
gdt_end:

gdt_descriptor:
    dw gdt_end - gdt_start - 1 ; GDT限长
    dd gdt_start ; GDT基址

; 启用A20地址线（必须步骤，否则无法访问1MB以上内存）
enable_a20:
    in al, 0x92
    or al, 0x2
    out 0x92, al
    ret

; 切换到保护模式
switch_to_pm:
    cli ; 禁用中断
    call enable_a20
    lgdt [gdt_descriptor] ; 加载GDT
    mov eax, cr0
    or eax, 0x1 ; 设置CR0的PE位（保护模式使能）
    mov cr0, eax
    jmp 0x08:pm_entry ; 远跳转到32位代码段，刷新CPU流水线

bits 32
pm_entry:
    ; 设置32位段寄存器
    mov ax, 0x10
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax
    mov ss, ax

    ; 跳转到内核入口点
    jmp 0x2140 ; 或者用jmp [0x2000 + 0x18]动态读取ELF入口

bits 16
boot:
    cli
    cld
    mov bh, 0xe
    mov bl, 0x18
    call MovCursor
    mov si, welcome_msg
    call Print

    ; 读取内核到0x2000
    mov ax, 0x200
    mov es, ax
    xor bx, bx
    mov al, 18
    mov ch, 0
    mov cl, 2
    mov dh, 0
    mov dl, 0
    mov ah, 0x02
    int 0x13
    jc .disk_err

    ; 切换到保护模式后执行内核
    call switch_to_pm

.disk_err:
    mov bh, 0xf
    mov bl, 0x15
    call MovCursor
    mov si, err_msg
    call Print
    hlt

%include "io.asm"

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

3. 验证内核编译选项 #

确保编译时生成32位目标文件：

• 汇编start.s：as --32 start.s -o start.o
• 编译kernel.c：gcc -m32 -ffreestanding -c kernel.c -o kernel.o
• 链接内核：ld -m elf_i386 -T kernel.lds start.o kernel.o -o kernel

4. GDB调试适配 #

调试时需要手动切换GDB的架构模式：

• 当执行到jmp 0x08:pm_entry时，在GDB中执行set architecture i386，让GDB正确解析32位指令。

三、总结 #

你的问题是实模式与保护模式不兼容、地址错位共同导致的执行流程混乱。先修正加载地址与链接地址的匹配，再添加完整的保护模式切换逻辑，就能解决调试时的异常行为。

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