uCore Lab1：从引导扇区到时钟中断的全链路拆解

操作系统实验做到 Lab1，很多人第一遍跑通就以为自己懂了——make qemu一敲，屏幕上刷出几行字，评分脚本全绿，收工。可真到答辩被问一句"你这行ljmp去掉会怎么样"，立马卡壳。uCore 的 Lab1 表面上只是"让内核打印一句话"，实际上它逼着你在一个没有任何操作系统帮忙的裸机环境里，亲手把加电自检、引导扇区、保护模式、磁盘读取、ELF 加载、中断框架这几件事从头串一遍。这篇就把 Lab1 这条链路拆开讲，讲清楚每一段汇编和每一行 C 代码是为了解决什么问题，哪些地方最容易翻车，以及调试的时候应该把断点下在哪。适合正在做实验卡住的同学，也适合做完想回头补一遍原理的人。

1. 从加电到第一行输出：Lab1 要打通的关键链路

先说清楚 Lab1 的整体目标，不然后面每一段代码都像是凭空冒出来的。这个实验的最终验收标准，是在 QEMU 里启动后能看到内核打印出的若干行信息：内核代码段、数据段、栈的地址范围，以及时钟中断累计的 ticks。为了走到那一步，你需要让一个 512 字节的引导扇区把后续的内核从磁盘里读出来、放到内存里、跳过去执行，而内核在被跳转过去之前还得把 CPU 从 16 位实模式切换到 32 位保护模式。

这条链路上每一步的"交付物"是可以明确列出来的，我习惯在做之前先把它写在纸上，做完一个划掉一个，比对着代码瞎看效率高得多：

1.1 先把 Makefile 和链接脚本读懂，比读代码更重要

我见过太多人上来就翻bootasm.S，看了半天不知道这段汇编被谁调用、被链接到哪个地址。Lab1 的第一个练习就是让你读 Makefile，这不是凑数。你需要搞清楚三件事：第一，bootblock是怎么由bootasm.S和bootmain.c编译链接出来的，链接地址为什么是0x7C00；第二，内核kernel被链接到哪个基址（这个实验里是0x100000，也就是 1MB 处）；第三，镜像文件是怎么把引导扇区放在最前面、内核接在后面的。

链接脚本里的地址决定了所有符号的绝对位置。引导扇区在0x7C00运行，内核在0x100000运行，两者差了将近 1MB。ELF 头里记录的入口地址e_entry是内核在链接时算好的绝对地址，所以bootmain.c里那句((void (*)(void))(ELFHDR->e_entry))()才能直接跳过去——它不需要做任何重定位，因为内核是按固定地址链接的。这个"不需要重定位"的前提，是整个实验能这么简单粗暴的根本原因，也是你后面做虚拟内存实验时必须推翻重来的地方。

还有个细节值得留意：objdump -h看内核的各段，你会发现.text、.data、.bss的地址是连续的，但.bss在文件里不占空间。这意味着引导扇区读进来的字节数小于内存中实际占用的字节数，.bss段必须在bootmain.c里手动清零。这一步漏掉，全局变量就是随机值，表现出来往往是"某个计数器一开始就是个奇怪的数"，非常难查。

1.2 引导扇区只有 512 字节，这是硬约束

整条链路里最容易被忽视的物理限制是：引导扇区必须恰好 512 字节，最后两个字节是0x55AA。链接脚本里通常有这么一段：

. = 0x7c00 + 510; .signature : { *(.signature) }

这行的意思是，把当前地址强制推进到0x7c00 + 510，然后在那里放签名。如果你的bootasm.S加bootmain.c编译出来超过 510 字节，链接器会报地址回退的错误，或者更糟——不报错但内容被截断，运行时跑飞。所以写bootmain.c的时候别想着引入标准库、别用printf、别定义大的静态数组，一切都要抠着来。

我第一次做的时候在bootmain.c里加了一堆调试用的全局变量，结果链接直接失败，报了一堆 "section .text will not fit in region" 之类的信息。后来把调试变量全删掉，改用outw(0x8A00, ...)往 QEMU 的调试端口写数据的方式打点，问题才定位下来。这个技巧后面在调试章节还会讲。

2. bootasm.S：实模式到保护模式的每一步都不能省

bootasm.S是整个实验里最"硬"的一段。它用 16 位汇编写成，从start:标号开始，一路把 CPU 从实模式推到保护模式，然后call bootmain。这一百来行代码几乎是每一行都对应一个历史遗留的坑，少写一行就出问题。

2.1 开头的cli和cld不是摆设

cli关中断、cld清方向标志。在实模式下，中断向量表位于0x0起始的内存区域，而这个区域正好是引导扇区加载后的低端内存。如果此时有中断进来，CPU 会去0x0附近取向量，那里的内容和 BIOS 时期留下的东西早就不匹配了，跳过去基本就是跑飞。所以进保护模式之前第一件事就是把中断关掉，等 IDT 建立好、idt_init做完之后再开会安全得多。

cld清的是方向标志 DF。开着 DF 的时候，串操作指令（movs、stos之类）会让指针反向递减。我们后面在bootmain.c里用insl从磁盘端口读数据，以及内核里用memset、memcpy处理数据，都依赖指针递增。虽然现代编译器生成的代码一般不会假设 DF 的状态，但在裸机环境里主动清一次是廉价的保险。

紧接着的xorw %ax, %ax加四条movw把ds/es/ss全部置零、movl $start, %esp设置栈指针，这几行的作用是建立一个临时的、可用的段环境和栈。注意栈是向低地址增长的，$start也就是0x7C00附近，往下长不会覆盖到引导扇区自身吗？会覆盖，但覆盖的是0x7C00以下的区域，而 BIOS 数据区、可用内存都在下面，只要不压到当前正在执行的代码，短时间用一下完全没问题。

2.2 A20 地址线那段握手到底在干什么

A20 是 x86 历史上最出名的一个兼容性包袱。早期的 8086 只有 20 根地址线，地址回绕到0xFFFFF之后会自动变成0x00000，很多老程序依赖这个行为。后来的 CPU 有了更多地址线，为了兼容，默认把第 21 根线（A20）拉低，物理上模拟回绕。问题是这样一来，你没办法访问 1MB 以上的内存，而保护模式下段基址可以到 4GB，不打开 A20 就完全没法用。

打开 A20 的经典做法是通过键盘控制器 8042 转发：

seta20.1: inb $0x64, %al testb $0x2, %al jnz seta20.1 movb $0xd1, %al outb %al, $0x64 seta20.2: inb $0x64, %al testb $0x2, %al jnz seta20.2 movb $0xdf, %al outb %al, $0x60

0x64端口是 8042 的状态/命令口，0x60是数据口。testb $0x2检查的是状态寄存器的第 1 位，也就是输入缓冲区是否还满着。满了就说明控制器还没忙完，必须自旋等待，否则你写进去的命令会被丢掉。第一轮往0x64写0xD1表示"接下来我要写输出端口"，第二轮往0x60写0xDF，这个字节的 bit1 就是 A20 的控制位，置 1 打开。用0xDF而不是0x02是为了顺带把其他位保持原样（这里取的是常见教程里的保守写法）。

这段代码看着简单，实际踩坑率很高。最常见的错误是把两个等待循环写反或者漏写，导致 A20 打开失败，表现是保护模式跳转后立刻三重故障，QEMU 直接重启，屏幕上什么都看不到。判断方法很简单：在ljmp之前插一句往0x8A00端口写数据的代码，如果能看到输出说明 A20 之前的都过了，看不到就是卡在 A20 或者 GDT 上。

2.3 打开 CR0.PE 之后为什么必须立刻远跳转

装 GDT 用lgdt gdtdesc，然后：

movl %cr0, %eax orl $CR0_PE_ON, %eax movl %eax, %cr0 ljmp $PROT_MODE_CSEG, $protcseg

CR0的 bit0 是保护模式使能位，置 1 之后 CPU 就进入保护模式了。但这时候CS寄存器里的内容还是实模式时期留下的段基址形式，CPU 会按保护模式的规则去解释它——把CS当作选择子，去 GDT 里查描述符。而实模式下的CS值通常是一个段地址（比如 0），对应到 GDT 的第 0 项，那是个全零的空描述符，加载它会触发通用保护异常。

ljmp的作用就是强制刷新CS。远跳转的指令格式里直接给出目标选择子和偏移，CPU 用新的选择子PROT_MODE_CSEG（这里是0x8，即 GDT 第 1 项、RPL=0）去查表，拿到代码段描述符，重新装载CS，跳转到protcseg。这一跳之后，CPU 才真正跑在保护模式的代码段里。

到了protcseg，还要把ds/es/fs/gs/ss全部换成数据段选择子0x10：

protcseg: movw $PROT_MODE_DSEG, %ax movw %ax, %ds movw %ax, %es movw %ax, %fs movw %ax, %gs movw %ax, %ss movl $0x0, %ebp movl $start, %esp call bootmain

这里重新设置了一次esp，因为实模式下的栈位置在低端内存，保护模式下虽然还能用，但为了保险起见把栈顶挪到0x7C00附近更干净。ebp清零是给调试器看的——GDB 回溯栈帧时靠ebp链，不清零会读到垃圾值，bt命令直接失效。

GDT 本身的构造在bootasm.S里用两个宏完成：

gdt: SEG_NULLASM SEG_ASM(STA_X|STA_R, 0x0, 0xffffffff) SEG_ASM(STA_W, 0x0, 0xffffffff) gdtdesc: .word (gdtdesc - gdt - 1) .long gdt

三个描述符：空描述符（CPU 规定第 0 项必须全零，加载它会触发异常，这是故意留的陷阱）、代码段（可读可执行）、数据段（可写）。两个段的基址都是 0、界限都是 4GB，这就是所谓的"平坦模型"——段机制形同虚设，所有寻址都靠偏移量。实验里这么做是为了简化，真正做 Lab2 之后你会发现分页才是主力。gdtdesc那 6 个字节是lgdt指令要求的格式：低 2 字节是界限减一，高 4 字节是 GDT 基址。(gdtdesc - gdt - 1)这个表达式算的就是"最后一个字节的偏移"，减一是因为界限值等于长度减一。

3. bootmain.c：把 ELF 从磁盘搬进内存并交出控制权

bootasm.S最后一句call bootmain把控制权交到了 C 代码手里。从这里开始工作内容变成了：从磁盘读数据、解析 ELF、跳到内核入口。听起来比汇编友好，但裸机环境下你连printf都没有，唯一的"输出"手段是往特定端口写数据或者直接操作显存。

3.1 readseg / readsect 的两段式封装是有道理的

磁盘读取在这套实验里用的是传统的 PATA 端口编程，主通道的端口基址是0x1F0。readsect负责读一个扇区（512 字节），readseg在其上封装，支持"从某个偏移开始读若干个字节"。

static void waitset(void) { while ((inb(0x1F7) & 0xC0) != 0x40); } static void readsect(void *dst, uint32_t secno) { waitset(); outb(0x1F2, 1); outb(0x1F3, secno & 0xFF); outb(0x1F4, (secno >> 8) & 0xFF); outb(0x1F5, (secno >> 16) & 0xFF); outb(0x1F6, ((secno >> 24) & 0xF) | 0xE0); outb(0x1F7, 0x20); waitset(); insl(0x1F0, dst, SECTSIZE / 4); }

waitset里读的是状态寄存器0x1F7，0xC0掩码保留最高两位，0x40表示"设备就绪、可以接收命令"。这个等待循环不能省，硬盘是机械/半机械设备，上一条命令没完成就发下一条，命令会被直接忽略，然后你读到的是一堆废数据。

0x1F2是扇区计数，读一个扇区就写 1。0x1F3到0x1F5是 LBA 地址的低 24 位。0x1F6比较特殊，低 4 位是 LBA 的高 4 位，bit4 置 1 表示主盘，bit6 置 1 表示 LBA 模式而不是柱面-磁头-扇区模式，所以0xE0这个常量就是1110_0000，位的含义一目了然。0x1F7写0x20是"读扇区"命令。最后insl从0x1F0数据端口连续读SECTSIZE/4个双字，也就是 128 个 32 位，正好 512 字节。

insl是个内联汇编封装，本质上是一条rep insl。注意它依赖方向标志 DF 为 0，这就是前面cld的意义之一。

readseg的实现要处理偏移和长度：

static void readseg(uintptr_t va, uint32_t count, uint32_t offset) { uintptr_t end_va = va + count; va -= offset % SECTSIZE; uint32_t secno = (offset / SECTSIZE) + 1; for (; va < end_va; va += SECTSIZE, secno++) { readsect((void *)va, secno); } }

注意secno = offset / SECTSIZE + 1里的+1，因为引导扇区本身占用了第 0 扇区（或者说 LBA 0），内核从 LBA 1 开始。这个+1忘了写，读进来的就是引导扇区自己，解析 ELF 头部时 magic 对不上，直接走bad分支死循环。这个坑我踩过，症状是屏幕一片黑、QEMU 也不退出，得用Ctrl+A再按X才能强制杀掉。

还有va -= offset % SECTSIZE这一句。如果要求从某个非扇区对齐的偏移开始读，实际只能整扇区读，所以要把目标地址往回退到扇区边界，让读进来的数据里包含需要的部分。这个"多读了也没关系"的假设成立，前提是目标地址前面有足够的可写内存空间，一般成立。

3.2 遍历程序段时的三个易错点

struct proghdr *ph = (struct proghdr *)((uintptr_t)ELFHDR + ELFHDR->e_phoff); struct proghdr *eph = ph + ELFHDR->e_phnum; for (; ph < eph; ph++) { readseg(ph->p_pa, ph->p_memsz, ph->p_offset); }

第一，ELFHDR临时放在0x10000（64KB 处），先读 8 个扇区也就是 4KB 过去，够放 ELF 头和程序头表。如果内核的程序头表特别大，4KB 可能不够，但这个实验里绰绰有余。

第二，p_pa是物理地址。ELF 里的p_vaddr是虚拟地址，在还没有分页的 Lab1 里两者相等，所以用p_pa。你如果顺手写成p_vaddr，在这个实验里碰巧也能跑，但理解上就埋了个雷。

第三，readseg的第三个参数是文件内偏移p_offset，不是内存地址。我见过有人把p_memsz和p_filesz搞混，用p_filesz去读，结果.bss段没被清零，全局变量全是脏数据。

清零.bss这件事必须自己做。ELF 加载完之后，对每个p_memsz > p_filesz的段，把[p_pa + p_filesz, p_pa + p_memsz)这段内存清零。忘记这一步的典型症状是：内核初始化时某个静态标志位一开始就是非零值，直接跳过了本该执行的初始化流程，然后你在kern_init里打断点发现它压根没进去。

最后的跳转：

((void (*)(void))(ELFHDR->e_entry))();

把入口地址强转成函数指针并调用。这一句没有返回地址的准备，也没有调用约定，纯粹是"跳过去就不回来了"。所以后面bad分支必须是个死循环，不能让执行流回到这里。

4. 中断框架：IDT、向量表与 trapframe 的搭建

内核入口kern_init里最先做的事通常是清.bss、初始化控制台、打印几行信息，然后是idt_init()和clock_init()，最后intr_enable()开中断。这几步的顺序不能乱：IDT 没建好就开中断，任何一个中断进来都会因为找不到处理程序而触发异常，异常又找不到处理程序，直接三重故障。

4.1 256 个入口是怎么批量生产出来的

x86 保护模式支持 256 个中断向量，每个都需要一个入口地址。手写 256 段汇编不现实，所以实验用了一个生成技巧：vectors.S里通过汇编宏和.rept指令批量生成入口，每个入口把中断号压栈，然后统一跳到__alltraps。

vector0: pushl $0 jmp __alltraps vector1: pushl $1 jmp __alltraps ...

这个数组的起始地址被导出成一个符号__vectors，C 代码里通过extern uintptr_t __vectors[]声明，拿到的就是这个符号的地址，也就是第 0 个入口的地址。遍历它就能把 256 个入口逐个注册到 IDT 里：

extern uintptr_t __vectors[]; for (int i = 0; i < sizeof(idt) / sizeof(struct gatedesc); i++) { SETGATE(idt[i], 0, GD_KTEXT, __vectors[i], DPL_KERNEL); }

这里有个容易犯的错：写成__vectors[i]拿到的确实是指令的地址，但如果你手滑写成&__vectors[i]，那就变成了数组元素的地址，也就是__vectors + i*4，跳过去执行的是数据，直接跑飞。区分方法很简单——__vectors被声明为uintptr_t[]，元素本身就是地址值，不需要再取地址。

4.2 idt_init 里几个字段的含义

SETGATE是个宏，展开后填的是中断门描述符的各个字段：

#define SETGATE(gate, istrap, sel, off, dpl) \ do { \ (gate).gd_off_15_0 = (uint32_t)(off) & 0xffff; \ (gate).gd_ss = (sel); \ (gate).gd_args = 0; \ (gate).gd_rsv1 = 0; \ (gate).gd_type = (istrap) ? STS_TG32 : STS_IG32;\ (gate).gd_s = 0; \ (gate).gd_dpl = (dpl); \ (gate).gd_p = 1; \ (gate).gd_off_31_16 = (uint32_t)(off) >> 16; \ } while (0)

几个字段值得说清楚。gd_off_15_0和gd_off_31_16是处理程序地址拆成的两段，中间夹着其他字段，这是 x86 历史包袱造成的非连续布局。gd_ss是目标代码段选择子，这里是内核代码段GD_KTEXT。gd_type区分中断门和陷阱门：中断门在进入时会自动关中断（清 EFLAGS 的 IF 位），陷阱门不会。时钟中断用中断门更合理，避免处理过程中被同一个中断反复打断。gd_p是存在位，必须置 1，否则访问这个描述符会触发段不存在异常。gd_dpl是特权级，内核态处理程序填 0，用户态能触发的系统调用才需要 3。

idt_init的最后一步是加载 IDTR：

extern struct pseudodesc idt_pd; asm volatile("lidt %0" : : "m"(idt_pd));

这个pseudodesc结构就是 6 字节：2 字节界限、4 字节基址，和前面lgdt用的格式一样。界限值是sizeof(idt) - 1。这个减一如果写错，比如忘了减或者多减了，lidt不会报错，但中断触发时 CPU 访问到界外的描述符，行为不可预测。

5. 时钟中断跑通：ticks 打印背后的完整调用链

Lab1 的验收里有一项是"每 100 个时钟中断打印一次 ticks"，很多人的实现是直接在trap_dispatch里判断并调用cprintf。功能上没问题，但如果被追问"从硬件定时器到你的printf一共经过了几层"，答不上来就说明只是抄了代码。

5.1 从 8253 到 trap_dispatch 的完整路径

时钟中断的源头是可编程间隔定时器，实验里通常把它的频率配成 100Hz，也就是每 10 毫秒一次。定时器到点后通过中断控制器把信号送到 CPU 的 IRQ0，CPU 查 IDT 第 32 项（IRQ_OFFSET + IRQ_TIMER，IRQ_OFFSET是 32），跳转到vector32，压栈中断号 32，跳到__alltraps。

__alltraps做的事：保存所有通用寄存器到一个trapframe结构、切换数据段寄存器、把当前的栈指针作为参数压栈、调用trap。trap在 C 里接收struct trapframe *tf，然后调trap_dispatch(tf)。分派逻辑大致是：

static void trap_dispatch(struct trapframe *tf) { if (tf->tf_trapno == IRQ_OFFSET + IRQ_TIMER) { ticks++; if (ticks % TICK_NUM == 0) { print_ticks(); } return; } print_trapframe(tf); panic("unhandled trap."); }

处理完返回trap，trap再把tf指针调整好，跳回__trapret，那边恢复寄存器、执行iret，回到被中断的指令继续执行。整条链路上任何一环出错，表现都差不多：要么完全不打印，要么打印一次之后卡死，要么直接 panic。

我第一次做的时候遇到一个很有意思的现象：ticks打印了两次之后就再也没动静了。用 GDB 一查，发现ticks变量确实在递增，但if里的条件没进。原因是ticks声明成了volatile之外的类型，编译器把ticks % TICK_NUM的结果缓存在寄存器里，循环里反复用旧值。加上volatile之后正常。这类问题在裸机上格外常见，因为没有任何运行时环境帮你兜底。

5.2 打印这件事在裸机上有多少前置条件

cprintf能用之前，得先有输出设备。实验里通常同时支持串口和并口（或者 VGA），clock_init之前必须先调serial_init之类的函数把设备初始化好，然后cprintf才有地方写字。

串口初始化要配四件事：波特率分频值（写0x3F8 + 0、0x3F8 + 1两个端口）、线路控制寄存器（0x3F8 + 3，设成 8 位数据位、1 位停止位、无校验，即0x03）、FIFO 控制（0x3F8 + 2，一般写0xC7清空并启用）、调制解调器控制（0x3F8 + 4，写0x0B使能数据终端就绪和请求发送）。这几个值我背了很久才记住，后来发现只要理解"串口是个极简的 UART，寄存器就那几个，配置项就那几样"，记不背都无所谓，现场查手册也能写。

cprintf的实现要点是：遇到%d就把整数按十进制拆位，遇到%x就按十六进制拆，遇到%s就逐字符输出，遇到换行要输出\r\n而不是单纯的\n——终端协议里光标回车和换行是两个独立动作，只发\n在某些终端下会往下走但不回行首，打印出来是斜的阶梯状。这个坑在做 Lab1 的时候经常能看到，屏幕上文字像楼梯一样斜着往下排。

往串口写一个字符的流程是：轮询0x3F8 + 5的 bit5（发送保持寄存器空），空了就往0x3F8 + 0写字符。这个轮询不能省，写太快会丢字符。测出来丢掉几个字符的时候，第一反应应该是查这里，而不是怀疑cprintf的格式化逻辑。

6. 调试链路：qemu 与 gdb 怎么配合着用

Lab1 有一半的练习量在调试上。裸机程序没有printf兜底，出问题只能靠 GDB 和端口打点。这套链路搭不起来，后面的实验基本没法做。

6.1 启动参数与断点位置

Makefile 里通常有qemu和debug两个目标。debug的启动命令里会带-S和-s：-S让 QEMU 启动后暂停等待调试器连接，-s是-gdb tcp::1234的简写。然后在另一个终端里：

gdb -ex 'target remote :1234' \ -ex 'file obj/bootblock.o' \ -ex 'break bootmain' \ -ex 'continue'

断点下在哪很有讲究。bootmain是个不错的起点，因为它意味着保护模式切换已经成功了。如果连这个断点都命中不了，问题一定在bootasm.S里，往下查的范围立刻缩小到一百行汇编。

想在汇编阶段下断点，用b *0x7c00。注意 GDB 连接上去的时候 CPU 还停在复位向量（0xF000FFF0附近），要先用si单步走一段固件代码才能到你的引导扇区。直接b *0x7c00然后c，QEMU 会自动跑到那个地址停下——前提是这个地址确实会被执行到。

进保护模式那段，我习惯在ljmp之前下一句b *0x7c2d（具体地址看反汇编），命中了就说明 GDT 装载没问题。如果在这里停下之后si一步就跑飞，那基本可以确定是ljmp的目标选择子错了，或者 GDT 描述符本身构造有问题，比如界限算错、基址写反。

调内核的时候，b kern_init是最直接的。如果这个断点命中不了，说明 ELF 加载出了问题，回去查e_entry和p_pa。命中了之后，b trap_dispatch观察中断有没有正常进来，p ticks看计数有没有递增，p *tf看 trapframe 的内容对不对。

6.2 常见失败现象与定位思路

做了几遍之后我把遇到过的问题整理成了下面这张表，新手照着查能省不少时间：

还有两个通用技巧值得记一下。第一个是 QEMU 的-d in_asm,int,cpu_reset参数组合，会把执行的指令、中断、复位事件全部记到日志文件里，卡死的时候翻日志往往能直接看到异常发生在哪条指令。第二个是往0x8A00端口写数据，QEMU 会把它当成调试输出打到 stderr，这个手段在连 GDB 都连不上的时候特别有用——因为它不依赖任何内存、任何栈，只要 CPU 还能执行outw指令就能工作。

7. 我在这几个练习里反复栽的坑

说几个具体到细节、看文档看不出来的问题。

一个是readseg的循环条件。我一开始写的是for (; va <= end_va; va += SECTSIZE)，多了个等号，结果多读了一个扇区，把内核后面的数据也读进了内存。这个实验里多读通常不致命，但如果你读的地址已经接近内存顶端，多读那 512 字节可能踩到不该碰的地方，表现为某个毫无关联的全局变量莫名其妙变了值。这种问题极难查，因为改的地方和出问题的地方隔着十万八千里。

另一个是 GDT 的界限值。(gdtdesc - gdt - 1)这个表达式里，gdt是标签地址，gdtdesc是描述符结构的地址，两者相减得到的是 GDT 的字节长度。如果误写成(gdtdesc - gdt)而忘了减一，界限就比实际大了 1，lgdt本身不报错，因为加载界限只是个赋值动作。但后续访问到最后一个字节之外的描述符索引时，CPU 的检查会失效，读到的是内存里的垃圾。这种"检查失效"型的问题比"检查报错"型难查十倍。

第三个是trapframe结构体和__alltraps里压栈顺序的对应关系。结构体的字段顺序必须和汇编里pushal加段寄存器的推入顺序严格一致，差一个字段，tf_trapno读到的就是别的值，trap_dispatch里所有分支判断全废。我在这一块上花的时间最多，因为症状是"中断明明进来了但就是不认中断号"，看起来像 IDT 注册错了，实际上是结构体对不上。校验的办法是在trap里把tf的地址和%esp的值同时打出来，确认两者的关系符合预期。

最后说个心得：Lab1 的评分脚本过了不代表懂了。我建议做完之后合上代码，自己在纸上把"从按电源键到打印 ticks"这条链路上每个关键动作画一遍，画不出来的地方就是没真懂的地方，回去补。这个实验的价值不在于最后那几行输出，而在于你亲手处理了一次"从零到有"的完整引导流程，后面做分页、做进程切换的时候，这套底层的直觉会一直用得上。