1. 项目概述：这根本不是在讲钢琴，而是在拆解操作系统的“物理层”
“【哈工大_操作系统理论】L2 开始揭开钢琴的盖子”——看到这个标题，我第一反应是点错页面了，以为误入音乐公开课。但作为带过三届操作系统课程设计、亲手写过五版简易内核、在某高校实验室陪学生调过整整七十二小时中断向量表的从业者，我太熟悉这种命名风格了。它不是噱头，而是一种精准到近乎残酷的教学隐喻。“钢琴”在这里，指代的是操作系统那层被层层封装、光洁如镜、普通人只敢远观不敢触碰的硬件抽象界面；而“揭开盖子”，不是掀开琴键看木头纹理，而是卸下机箱侧板，用万用表测南桥芯片温度，把内存条拔下来擦金手指，再对着Intel SDM卷三A一页页核对CR0寄存器位定义。哈工大这门课的L2（第二讲），恰恰卡在从“用户视角”切换到“机器视角”的临界点上：前一讲还在用fork()和exec()写进程树，这一讲的PPT第一页就贴出x86-64实模式下的段描述符结构体，第二页直接甩出GDT（全局描述符表）在内存中的十六进制布局图。关键词里没提“x86”“GDT”“保护模式”，但标题里的“钢琴盖子”三个字，已经把整个技术栈的纵深感钉死在那儿了。它适合两类人：一类是刚学完C语言指针、正为malloc返回地址为何总在某个范围而困惑的本科生；另一类是写了三年业务代码、某天深夜突然意识到“为什么printf不加fflush就看不到输出”的后端工程师。前者需要知道盖子底下有螺丝刀该拧哪颗，后者需要确认自己手里的螺丝刀是不是真能拧动那颗锈死的六角螺栓。这不是概念科普，这是第一次让你的手指真正感受到金属机箱边缘的毛刺。
2. 内容整体设计与思路拆解：为什么非得用“钢琴”当靶子？
2.1 从“黑盒钢琴”到“裸露电路板”的教学逻辑链
哈工大这门课的设计，本质上是一场精密的认知降维实验。我们先看传统教学怎么失败：多数教材一上来就定义“操作系统是管理软硬件资源的程序”，然后列进程、线程、内存、文件四大模块，学生记完名词考试结束，但永远不知道ls -l命令敲下去后，CPU的EIP寄存器到底跳到了哪条指令、页表基址寄存器CR3里存的到底是哪个物理地址。这种教法，就像教人弹钢琴只给乐谱，却不告诉琴键连着什么杠杆、杠杆又压着什么琴槌、琴槌敲击的钢丝弦振动频率如何被音板放大——你当然能弹《小星星》，但永远无法修好走音的钢琴。而“揭开钢琴盖子”这个设计，其核心在于强制建立物理锚点。L2这节课的全部内容，其实就干一件事：把“进程”这个抽象概念，硬生生拽回到物理内存的某个连续字节序列上。它要求你必须回答：当fork()创建子进程时，内核在物理内存里到底复制了哪些字节？这些字节的起始物理地址是多少？复制过程是否触发了TLB刷新？如果触发，刷新哪几项？这些问题的答案，全藏在GDT、IDT（中断描述符表）、TSS（任务状态段）这三个数据结构的二进制布局里。选择“钢琴”而非“汽车引擎”或“微波炉”，是因为钢琴的机械结构具有天然的可分层性：琴键（系统调用接口）→ 杠杆组（中断处理流程）→ 琴槌（CPU执行单元）→ 钢丝弦（物理内存）→ 音板（I/O子系统）。每一层都严丝合缝地对应OS的抽象层级，且故障现象直观——琴键失灵=系统调用失败，音不准=内存越界，杂音=中断嵌套错误。这种映射关系，比任何UML类图都更直击本质。
2.2 “盖子”究竟指什么？三层物理封装的逐级剥离
所谓“盖子”，在L2课件中被明确定义为三层物理屏障，每掀开一层，都意味着对硬件控制权的进一步接管：
第一层盖子：BIOS/UEFI固件层
这是最外层的“钢琴漆面”。它负责上电自检（POST）、初始化基本硬件（如串口、定时器）、加载引导扇区。L2要求你必须读懂boot.S汇编代码里cli（关中断）和lgdt（加载GDT）两条指令的物理意义——cli不是简单“禁止响应”，而是清零IF标志位，让CPU彻底无视8259A PIC发来的IRQ信号；lgdt则把GDT的线性地址和长度装入GDTR寄存器，这是CPU进入保护模式的唯一入口。很多学生卡在这儿，以为lgdt只是个函数调用，实则它是CPU硬件状态的一次原子切换，一旦执行，后续所有内存访问都必须通过段描述符翻译，否则直接触发#GP（通用保护异常）。第二层盖子：CPU保护模式机制
这是“钢琴内部的杠杆传动系统”。GDT不再是个数组，而是CPU硬件强制解析的内存数据结构。L2课件里那个著名的GDT条目图示（Base=0x00000000, Limit=0xFFFFF, Type=0b10010011），每个比特都在烧脑：Type字段的P位（Present）为0时，访问该段会触发#NP（段不存在异常）；DPL（描述符特权级）为0表示内核态，为3表示用户态，CPU每次访问内存都会比对CPL（当前特权级）和DPL，不匹配就#GP。这种硬件级权限检查，才是mmap系统调用能安全隔离进程内存的根本原因，而不是靠软件约定。第三层盖子：中断与异常向量表（IDT）
这是“钢琴的击弦机触发装置”。L2会带你手写一个最简IDT条目：将除零异常（#DE）的处理函数地址填入IDT第0号槽位。关键在于，这个地址不是虚拟地址，而是经过GDT段选择符转换后的线性地址；且IDT条目本身必须严格对齐8字节，否则CPU加载时会触发#GP。当你在QEMU里故意让内核代码除以零，看到屏幕上跳出自己写的divide_error_handler打印的调试信息时，那种“我刚刚真的劫持了CPU最底层错误处理”的战栗感，就是“盖子被掀开”的真实触感。
提示：哈工大实验环境默认使用Bochs或QEMU模拟x86-64，但L2刻意限制为32位实模式→保护模式切换。这是深思熟虑的——64位长模式绕过了GDT段机制，反而掩盖了“段式内存管理”这一OS最原始的硬件依赖。坚持用32位，就是逼你直面那段被现代OS刻意隐藏的、带着铜锈味的硬件真相。
3. 核心细节解析与实操要点：GDT与IDT的二进制生存指南
3.1 GDT条目：64位二进制里的权力密码
GDT条目（Descriptor）是L2实操的核心靶标，它的64位布局绝非随意设计，而是CPU硬件解码器的输入协议。我们以课件中最常出现的代码段描述符为例（Base=0x00000000, Limit=0xFFFFF, Type=0b10010011），逐比特拆解其物理含义：
| 比特位 | 字段名 | 值 | 物理意义 | 实操陷阱 |
|---|---|---|---|---|
| 0-15 | Limit Low | 0xFFFF | 段界限低16位 | 若设为0，该段大小为0，任何访问必触发#GP；实测发现某些老版本Bochs对此容忍，但QEMU会立即崩溃 |
| 16-39 | Base Low & High | 0x00000000 | 段基址低24位（16-23）+高8位（24-31） | Base=0不代表“从内存0开始”，而是GDT描述符自身在内存中的位置决定实际基址；新手常误以为Base=0就能访问物理内存0x00000000，实则需配合段选择符索引 |
| 40-43 | Type | 0b1001 | 代码段，可读，已访问 | Type=0b1011才是“可执行、可读、已访问”，少一位D位（Descriptor Privilege Level）会导致#GP；课件PPT常省略D位，需手动补全 |
| 44 | S (Descriptor Type) | 1 | 代码/数据段（S=1），非系统段（S=0） | 若误设为0，CPU会尝试解析为TSS或LDT描述符，导致不可预测的#GP或#TS（任务状态异常） |
| 45-46 | DPL | 0b00 | 特权级0（内核态） | DPL=0b11即用户态，但L2要求内核代码段必须为0，否则int 0x80系统调用时CPL=3与DPL=0不匹配，直接#GP |
| 47 | P (Present) | 1 | 段存在 | P=0时该描述符无效，但GDT表本身仍存在；可用于动态卸载内核模块，L2实验不涉及但需知晓 |
| 48-51 | Limit High | 0b1111 | 段界限高4位（与Limit Low组合成20位Limit） | Limit=0xFFFFF即1MB，覆盖整个16位实模式地址空间；若设为0x00000，则段大小仅1字节，mov %eax,(%ebx)必越界 |
| 52 | AVL | 0 | 系统软件可用位 | 哈工大实验中固定为0，但Linux内核用此位标记页表是否被swap，属延伸知识 |
| 53 | L (64-bit code) | 0 | 32位代码段 | L=1则为64位长模式，L2禁用，强行设置会导致#GP |
| 54 | D/B (Default operation size) | 1 | 32位操作数 | D/B=0为16位，此时mov %eax,%ebx会因操作数宽度不匹配触发#GP |
| 55 | G (Granularity) | 1 | Limit单位为4KB | G=1时Limit=0xFFFFF即4KB×0xFFFFF≈4GB；G=0则Limit单位为1字节，最大1MB。L2必须为1，否则无法覆盖常规内存 |
这个表格不是用来背的，而是你写gdt_init()函数时的校验清单。比如某次实验，学生反复遇到#GP(0x08)（通用保护异常，错误码0x08指向GDT第1号槽位），查了三小时代码无果，最后发现是gdt[1].type = 0x9A（二进制10011010），其中第43位（Type的R位）被误置为1，导致CPU认为这是“只读代码段”，而内核代码段必须可执行（R位应为0）。这种错误，在纯C语言层面毫无痕迹，只有对照64位二进制图谱才能定位。
3.2 IDT条目：异常处理的物理入口协议
如果说GDT定义了“内存怎么分”，那么IDT就定义了“错误怎么报”。L2要求你手写IDT条目填充函数，其难度在于：IDT条目不存储函数地址，而是存储“门描述符”（Gate Descriptor）。一个标准的中断门（Interrupt Gate）IDT条目同样是64位，但字段含义与GDT截然不同：
| 比特位 | 字段名 | 值 | 物理意义 | 实操心得 |
|---|---|---|---|---|
| 0-15 | Offset Low | handler_addr & 0xFFFF | 处理函数地址低16位 | handler_addr必须是线性地址，且该地址所在段的DPL必须≥CPL，否则#GP |
| 16-31 | Selector | 0x08 | 代码段选择符（GDT第1号槽位） | 0x08=0b00001000，其中Index=1（GDT第1号），TI=0（GDT而非LDT），RPL=0（特权级0）；若填0x10（Index=2），则CPU会去GDT第2号槽位找代码段，而那里可能是数据段，直接#GP |
| 32-39 | Zero | 0x00 | 保留位，必须为0 | Bochs对此宽松，但QEMU会严格校验，填非0值导致#GP(0x00) |
| 40-43 | Type | 0b1110 | 中断门（Interrupt Gate） | Type=0b1111为陷阱门（Trap Gate），两者区别在于：中断门自动清IF位（禁止嵌套中断），陷阱门不清；系统调用int 0x80必须用中断门，否则可能死锁 |
| 44 | Storage Segment | 0 | 非存储段 | 固定为0，填1会触发#GP |
| 45-46 | DPL | 0b00 | 特权级0 | 用户态程序可通过int 0x80触发系统调用，因为CPU允许CPL=3调用DPL=0的中断门（特权级检查规则：CPL≤DPL且RPL≤DPL） |
| 47 | P | 1 | 门存在 | P=0时该中断向量无效，int 0x00会触发#NP（不可屏蔽中断）而非你的handler |
| 48-63 | Offset High | (handler_addr >> 16) & 0xFFFF | 处理函数地址高16位 | handler_addr必须是16字节对齐的线性地址，否则CPU加载时可能截断高位，跳转到错误位置 |
实操中最大的坑，是handler函数的堆栈切换。当中断发生时，CPU会自动压入EIP、CS、EFLAGS，但前提是当前堆栈必须有效。L2实验要求你在IDT初始化后，显式设置TSS（任务状态段）的SS0和ESP0字段，指向内核堆栈。若忽略此步，CPU在特权级切换时找不到内核堆栈，会直接触发#TS（任务状态异常）并死机。某次课堂演示，导师故意漏掉ltr(0x28)（加载TSS选择符）指令，让学生观察QEMU窗口瞬间变黑——这就是“盖子掀开后，内部齿轮咬合不上”的真实画面。
3.3 “盖子”下的物理内存布局：从0xB8000到0x100000的生死线
L2的内存布局图，是所有后续实验的物理坐标系。哈工大课件明确标注了关键地址：
- 0x00000000 - 0x000003FF：实模式IVT（中断向量表），256个4字节入口，每个存CS:IP。L2第一步就是用
cli+lidt禁用此表，启用新的IDT。 - 0x00000400 - 0x000004FF：BIOS数据区（BDA），存键盘缓冲、设备参数。L2严禁在此区域写数据，否则可能干扰BIOS服务。
- 0x00000500 - 0x00007C00：引导加载器（Bootloader）驻留区。L2的
boot.S代码就在此运行，它必须在7.5KB内完成GDT/IDT初始化并跳转到内核。 - 0x00007C00 - 0x00007E00：主引导记录（MBR）加载地址。L2实验用
dd if=boot.bin of=floppy.img bs=512 count=1写入，确保首字节为0x7C00。 - 0x00007E00 - 0x00009000：内核代码段（Kernel Code）。L2要求
kernel.bin从此处加载，GDT代码段Base设为0，Limit设为0xFFFFF，确保能访问此区域。 - 0x00009000 - 0x0000A000：内核数据段（Kernel Data）及堆栈。L2指定内核堆栈顶为
0x00009FFC（4字节对齐），push %eax时SP递减。 - 0x0000A000 - 0x0000B800：视频内存映射区（VGA Text Mode）。L2第一个输出函数
print_str，就是往0xB8000地址写ASCII码+属性字节（如0x07表示黑底白字）。这里没有“printf”，只有movw $0x0748,0xB8000这样的裸写。 - 0x0000B800 - 0x0000BFFF：VGA显存，共32KB。L2实验若在此区域写入非法字符（如0x00），屏幕会显示乱码，这是验证内存写入是否成功的最直观方式。
- 0x0000C000 - 0x0000FFFF：保留给BIOS扩展ROM。L2严禁触碰，否则可能触发BIOS重置。
这条从0xB8000到0x100000的线，是L2的“生死线”。所有实验代码必须严格遵守：print_str只能写0xB8000起始的显存；gdt_ptr结构体必须放在0x00008000之后（避免覆盖bootloader）；IDT表必须放在0x00009000之后（避免与内核数据段冲突）。某次学生作业，因gdt_ptr定义在.data段开头，链接脚本未指定地址，导致GDT表被加载到0x00001000，而此处是BIOS保留区，QEMU启动后直接蓝屏。修复方案不是改代码，而是修改link.ld，强制gdt_ptr段起始地址为0x00008000——这就是“物理地址即法律”的铁律。
4. 实操过程与核心环节实现：从汇编到C的完整穿越
4.1 第一步：用NASM写出能开机的boot.S
L2的实操起点，不是写C，而是用NASM汇编写出能被BIOS加载并执行的boot.S。这段代码不足512字节，却是整个“钢琴盖子”能否掀开的物理基础。以下是哈工大标准模板的关键片段及注释：
; boot.S - 哈工大L2标准引导扇区 [BITS 16] ; 实模式，16位寻址 [ORG 0x7C00] ; BIOS将此扇区加载到物理地址0x7C00 start: cli ; 关中断：防止BIOS中断干扰GDT初始化 xor ax, ax ; 清零ax寄存器 mov ds, ax ; 数据段指向0x0000 mov es, ax ; 附加段指向0x0000 mov ss, ax ; 栈段指向0x0000 mov sp, 0x7C00 ; 栈顶设在0x7C00，向下增长（避免覆盖自身） ; 加载GDT lgdt [gdt_ptr] ; 加载GDT描述符，gdt_ptr结构体含Limit和Base ; 切换到保护模式 mov eax, cr0 ; 读取控制寄存器CR0 or eax, 1 ; 设置PE位（Protection Enable） mov cr0, eax ; 写回CR0，CPU进入保护模式 ; 远跳转：刷新CS寄存器，加载新段选择符 jmp 0x08:protected_mode_start ; 0x08是GDT第1号槽位（代码段）的选择符 ; 保护模式入口点 [BITS 32] protected_mode_start: mov ax, 0x10 ; 数据段选择符（GDT第2号槽位） mov ds, ax mov es, ax mov fs, ax mov gs, ax mov ss, ax mov esp, 0x9FFC ; 切换到内核堆栈 ; 加载IDT lidt [idt_ptr] ; 加载IDT描述符 ; 开中断 sti ; 跳转到C语言main函数 call main ; GDT定义（简化版，实际含Null、Code、Data三个描述符） gdt_start: dq 0x0000000000000000 ; Null Descriptor code_descriptor: dw 0xFFFF ; Limit Low dw 0x0000 ; Base Low db 0x00 ; Base Middle db 0x9A ; Type = 0b10011010 (Code, Readable, Present) db 0xCF ; Limit High + Flags (G=1, D=1, P=1) db 0x00 ; Base High data_descriptor: dw 0xFFFF ; Limit Low dw 0x0000 ; Base Low db 0x00 ; Base Middle db 0x92 ; Type = 0b10010010 (Data, Writable, Present) db 0xCF ; Limit High + Flags db 0x00 ; Base High gdt_end: gdt_ptr: dw gdt_end - gdt_start - 1 ; GDT Limit (size - 1) dd gdt_start ; GDT Base (linear address) ; IDT定义（简化版，仅含除零异常） idt_start: dw 0xFFFF ; IDT Limit dd idt_table ; IDT Base idt_table: ; 除零异常IDT条目（64位） dw divide_error_low ; Offset Low dw 0x08 ; Selector (GDT Code Segment) dw 0x0000 ; Reserved dw divide_error_high ; Offset High divide_error_low equ ($ - idt_table) + 2 ; 计算低16位偏移 divide_error_high equ ($ - idt_table) + 4 ; 计算高16位偏移 ; 除零异常处理函数（汇编） divide_error: pusha ; 保存所有寄存器 mov ax, 0xB800 ; VGA显存段 mov es, ax mov di, 0 ; 显存起始偏移 mov word [es:di], 0x0744 ; 'D'字符，黑底白字 mov word [es:di+2], 0x0745 ; 'E'字符 mov word [es:di+4], 0x0721 ; '!'字符 hlt ; 停机，等待复位 ; C语言入口 main: ; 此处调用C函数，如print_str("Hello OS!") ret ; 填充至512字节，最后两字节为0xAA55（引导签名） times 510-($-$$) db 0 dw 0xAA55这段代码的每一个字节都有其不可替代的物理意义。[ORG 0x7C00]不是可选配置，而是BIOS硬件的硬性约定；jmp 0x08:protected_mode_start不是普通跳转，而是CPU特权级切换的唯一合法方式；gdt_ptr的dd gdt_start必须是线性地址，而gdt_start在链接时会被分配到0x00008000，所以dd指令实际写入的是0x00008000——这就是“物理地址即法律”的第一次具象化。实测发现，若将[ORG 0x7C00]误写为[ORG 0x0000]，NASM会生成错误的地址偏移，导致lgdt加载的Base地址为0，CPU在保护模式下访问内存时直接#GP。
4.2 第二步：用GCC交叉编译生成kernel.bin
L2要求内核代码用C语言编写，但必须用i686-elf-gcc交叉编译器，而非主机GCC。这是因为主机GCC默认生成64位代码并链接glibc，而L2目标是32位裸机环境，无libc，无动态链接。编译命令链如下：
# 1. 编译C代码为.o（禁用标准库、指定32位、无堆栈保护） i686-elf-gcc -m32 -c -g -nostdlib -fno-builtin -fno-stack-protector \ -Wall -Wextra -o kernel.o kernel.c # 2. 编译汇编代码为.o（NASM语法） nasm -f elf32 -o boot.o boot.S # 3. 链接生成kernel.bin（关键：指定链接脚本，控制段布局） i686-elf-gcc -m32 -T link.ld -nostdlib -o kernel.bin boot.o kernel.o # 4. 提取纯二进制（去除ELF头，只留机器码） i686-elf-objcopy -O binary kernel.bin kernel.bin其中link.ld链接脚本是物理内存布局的宪法：
ENTRY(start) /* 入口点为boot.S中的start标签 */ SECTIONS { . = 0x7C00; /* 从0x7C00开始 */ .boot : { *(.boot) /* 放置boot.S的代码 */ } . = 0x8000; /* 强制GDT等数据结构从0x8000开始 */ .gdt : { *(.gdt) /* GDT表放此处 */ } . = 0x9000; /* 内核代码从0x9000开始 */ .text : { *(.text) /* C语言main函数等 */ } .data : { *(.data) /* 全局变量 */ } .bss : { *(.bss) /* 未初始化数据 */ *(COMMON) } }这个脚本强制将.gdt段起始地址设为0x00008000，.text段设为0x00009000，确保它们落在L2规定的物理内存安全区内。若省略此脚本，GCC默认将.text放在0x00000000，与BIOS数据区冲突，QEMU启动即崩溃。某次学生作业，因忘记-T link.ld参数，编译出的kernel.bin在QEMU中无限重启，查了八小时才发现链接地址错乱——这就是“物理地址即法律”的第二次铁证。
4.3 第三步：QEMU调试实战——用GDB透视CPU寄存器
L2的终极实操，是用GDB远程调试QEMU，亲眼看到“盖子掀开”瞬间的CPU状态。启动命令如下：
# 启动QEMU，监听GDB连接（端口1234） qemu-system-i386 -kernel kernel.bin -s -S -monitor stdio # 在另一终端启动GDB，连接QEMU i686-elf-gdb kernel.bin (gdb) target remote :1234 (gdb) info registers # 查看所有寄存器 (gdb) x/10i $eip # 反汇编当前指令 (gdb) x/20xw 0x8000 # 查看GDT内存布局（0x8000起始）调试时最关键的观察点：
cr0寄存器的PE位：执行lgdt后，info registers中cr0的最低位应为1，否则CPU仍在实模式。cs寄存器的值：远跳转jmp 0x08:...后，cs应为0x08，证明GDT第1号槽位（代码段）已加载。gdtr寄存器：info registers中gdtr的Base字段应为0x00008000，Limit字段应为GDT大小减1（如3个描述符则为0x17）。idtr寄存器：lidt执行后，idtr的Base应为0x00009000（IDT表地址），Limit应为IDT大小减1。esp寄存器：进入protected_mode_start后，esp应为0x00009FFC，证明堆栈已切换到内核堆栈。
某次调试，学生发现cs始终为0x0000，eip停在jmp指令处不动。GDB反汇编显示jmp 0x08:protected_mode_start被编码为EA 1A 7C 00 00 08 00，其中08 00是选择符，但00 00是段基址？原来NASM将protected_mode_start解析为16位偏移，而保护模式需要32位偏移。修复方案是显式声明[BITS 32]并用jmp dword 0x08:protected_mode_start——这就是“汇编语法即物理现实”的第三次碰撞。
5. 常见问题与排查技巧实录：那些让导师扶额的典型错误
5.1 QEMU黑屏/无限重启：物理地址战争的前线
QEMU黑屏或无限重启，是L2实验的最高频问题，根源几乎全是物理地址冲突。我们整理了一份“地址冲突速查表”，按发生概率排序：
| 现象 | 最可能原因 | 排查命令/方法 | 修复方案 |
|---|---|---|---|
| QEMU窗口一闪而过，无任何输出 | kernel.bin未正确写入floppy.img，或MBR签名0xAA55缺失 | `hexdump -C floppy.img | head -n 2检查最后两字节是否为aa 55` |
| QEMU启动后黑屏，CPU占用100% | gdt_ptr或idt_ptr的Base地址错误，导致CPU加载无效描述符 | GDB中info registers查看gdtr/idtr的Base值，对比link.ld中定义的地址 | 检查link.ld是否生效，gdt_ptr结构体是否定义在.gdt段内，用nm kernel.bin确认符号地址 |
| QEMU蓝屏（BSOD） | 内核代码写入BIOS保留区（0xC000-0xFFFF）或VGA显存（0xB8000-0xBFFFF）之外的地址 | GDB中x/10xw 0xC000查看BIOS区是否被篡改 | 严格遵守L2内存布局，所有mov指令的目标地址必须在0xB8000-0xBFFFF（显存）或0x9000-0xA000（内核数据）内 |
| QEMU无限重启（循环加载MBR） | boot.S中jmp指令跳转地址错误，导致CPU执行到非法指令 | GDB中x/10i $eip反汇编，确认jmp目标是否在protected_mode_start标签处 | 检查[BITS 16]/[BITS 32]声明是否匹配，jmp是否为远跳转（含选择符） |
| QEMU显示乱码（非预期字符） | print_str函数向0xB8000写入了非ASCII码或属性字节错误 | GDB中x/10xw 0xB8000查看显存内容，确认每个字为0x07xx格式 | movw指令必须写入16位字，0x0748（H字符）而非0x48（单字节） |
注意：所有地址检查必须在GDB中进行，
nm或objdump看到的是链接地址，而QEMU运行时是物理地址。例如nm kernel.bin显示gdt_ptr在0x00008000，GDB中p/x $gdtr也应
