1. 先搞清楚 ucore Lab1 在整门操作系统课里的位置1.1 这个实验到底让你做什么操作系统这门课最尴尬的地方在于课本上讲进程调度、虚拟内存、文件系统讲得头头是道可你合上书脑子里其实还是空的——因为你从来没真正看过一个操作系统从加电到跑起来的那几百行核心代码。ucore Lab 1 就是来填这个坑的。它不要求你从零手搓一个 OS而是给你一个已经能跑的最小内核骨架让你把“机器上电之后到底发生了什么”这条链路亲手走一遍。具体到 Lab 1你需要完成的动作可以概括成几个关键词看懂make是怎么把一堆.c、.S文件编译链接成一张可引导镜像的用 qemu 把这个镜像跑起来并用 gdb 接进去调试读懂 bootloader 怎么从实模式切到保护模式弄明白它怎么解析 ELF 格式把内核搬进内存最后还要动手实现一个堆栈回溯函数、把中断描述符表初始化完整、再让时钟中断每过 100 个 tick 打印一次提示。这一套下来你对“操作系统启动”这件事的理解会从“背概念”变成“真见过”。适合谁看这篇正在上操作系统实验课、被 ucore 的 Makefile 和汇编绕晕的同学想了解 x86 保护模式与中断机制但不想直接啃 Intel 手册的开发者以及准备考研 408 里操作系统部分想拿点真东西加深印象的人。哪怕你之前没碰过汇编只要肯跟着走Lab 1 的复杂度是可控的。1.2 为什么说 Lab1 是后面所有实验的地基我见过不少人做 Lab 1 的时候图省事直接把答案抄上去能跑通就交差结果到 Lab 2 物理内存管理、Lab 3 虚拟内存的时候整个人都是懵的。原因很简单后面所有实验都建立在“中断能正常进、内核能正常跑、栈能正常回溯”这三个前提上。Lab 1 没搞扎实后面每加一个功能都是往沙子上盖楼。拿中断来说Lab 1 里你把 IDT 填好、把__alltraps到trap这条路径打通后面 Lab 2 做页错误处理、Lab 3 做缺页异常、Lab 4 做系统调用走的都是同一套陷门机制只是把不同的中断向量挂上不同的处理函数。你要是 Lab 1 的trap_dispatch都没写明白后面遇到page fault只能干瞪眼。再比如堆栈回溯print_stackframe看着只是调试工具但它背后是函数调用约定ebp链这套硬知识你不理解栈帧布局后面调试任何内核崩溃都会抓瞎。所以我的建议是Lab 1 宁愿慢一点、把每个练习的“为什么”都写清楚也别急着往下赶。这一章的投入会在后面几章成倍地还给你。下面我就按我当年做实验的顺序把环境、构建、bootloader、中断这几块掰开揉碎讲一遍。2. 实验环境与构建链路从 make 到可引导镜像2.1 工具链准备与版本选择ucore 是个有点年头的教学项目对工具链版本比较敏感别上来就装最新版容易踩到莫名其妙的坑。我的建议是直接用 Ubuntu 18.04 或 20.04 这类比较稳的发行版或者干脆在虚拟机里跑省得污染你自己的开发机。需要的核心工具就几样gcc要能生成 32 位代码所以得装gcc-multilib、make、qemu-system-i386、gdb以及 binutils 里的objdump、objcopy、ld。这里有个新手常踩的坑现在很多机器是 64 位的默认gcc也是 64 位的但 ucore 编出来的是 32 位内核。你要么在 Makefile 里指定-m32要么确保装了 multilib 支持。实测下来最省事的做法是sudo apt install build-essential gcc-multilib qemu-system-i386 gdb。装完之后用qemu-system-i386 --version确认一下 qemu 能识别 32 位系统模拟。版本上有两个具体注意点。第一gcc 太新比如 10 以上对某些老代码的警告会升级成错误如果编译报一堆-Werror可以在 Makefile 里把-Werror去掉或者降级用 gcc-7 之类。第二qemu 版本太新时-kernel加载和-s -S调试接口的行为略有差异但基本兼容遇到问题优先看是不是参数写错了而不是怀疑版本。提示不要用 WSL1 做这个实验它的 gdb 与 qemu 协作经常出问题。WSL2 可以但调试端口转发要单独配新手建议直接上原生 Linux 或 VMware 里的 Ubuntu。2.2 ucore.img 是怎么一步步拼出来的这是练习 1 的核心。很多人第一次看 ucore 的 Makefile 会头大因为它有递归、有条件编译、有objcopy转角但你把链条画出来其实不复杂。最终目标是生成一张ucore.img这张镜像前 512 字节是 bootloader后面紧接着是内核 ELF。qemu 把它当成一块硬盘或者用-kernel直接加载从上电开始跑。我把构建的关键步骤列出来你可以对照 Makefile 里的目标看bootasm.S和bootmain.c先各自编译成.o再链接成bootblock.o用objcopy -O binary把bootblock.o抽成纯二进制bootblock.out再补上sign工具加的一个 0x55AA 魔数这是引导扇区的标志内核那一侧一堆.c和.S先编成.o用kernel.ld脚本链接成kernel最后用sign工具把bootblock和kernel拼接成ucore.img。这里kernel.ld是重点。它规定了内核代码从哪个虚拟地址开始放。ucore 里内核链接地址是0xC0100000但物理加载地址是0x1000001MB。为什么要差这0xC0000000因为 ucore 后面要做虚拟内存把内核映射到高地址区那个偏移量是给分页机制留的。Lab 1 阶段虽然还没开分页但链接脚本已经按这个约定写好了bootmain 加载 ELF 时也要把程序头里记录的虚拟地址减掉这个偏移算回真实的物理地址再拷贝。注意练习 1 通常会让你回答“bootblock 和 kernel 分别被加载到哪个地址、为什么”。答案要落到0x7c00bootloader 被 BIOS 加载的位置和0x100000内核物理加载位置这两个数上别只写个大概。理解这条链条的意义在于以后你改任何内核代码都要清楚它最终是怎么进入镜像、又是怎么被加载的。有一次我改了个内核函数结果运行没变化排查半天才发现是make没有重新生成kernel因为依赖关系被我用一个错误的写法破坏了。构建系统这东西你以为它理所当然其实很容易出问题。2.3 qemu 启动与 GDB 双机调试接入镜像有了接下来是跑起来和调试。启动命令一般长这样qemu-system-i386 -hda bin/ucore.img -monitor stdio -s -S-s是-gdb tcp::1234的简写意思是 qemu 开一个 gdb server 监听 1234 端口并冻结 CPU 等待调试器接入-S表示启动时先暂停。然后你另开一个终端gdb bin/kernel (gdb) target remote :1234 (gdb) b kern_init (gdb) c这样就能在内核入口处断下来。我强烈建议你在bootasm.S开头、bootmain入口、kern_init三处都下断点单步走一遍感受从 16 位实模式到 32 位保护模式的切换过程。看寄存器cr0的 PE 位从 0 变 1 那一刻比看十页课本都直观。调试时有个小技巧qemu 冻结在-S状态时用info registers看到的还是实模式寄存器。等你si单步过保护模式切换那几条指令之后再info registers就会看到 32 位寄存器段选择子变成 0x8、0x10 这种。这一步是验证你 GDT 写对没有的最快方法。提示gdb 里x/10i $eip反汇编当前位置的指令非常有用配合si单步你会看到保护模式切换前后的指令编码长度都不一样16 位和 32 位指令前缀不同。2.4 一张表理清关键地址与端口实验里涉及不少魔数初学时容易记混我整理了一张表贴在显示器旁边会省很多回翻文档的时间。名称数值/端口作用说明引导扇区加载地址0x7C00BIOS 把第一扇区搬到内存的位置内核物理加载地址0x1000001MB 处bootmain 把 ELF 段拷到这里内核链接虚拟地址0xC0100000链接脚本约定的高地址A20 使能端口0x64/0x60键盘控制器置位第 2 位打开 A20CR0 PE 位bit 0置 1 进入保护模式内核代码段选择子0x08GDT 第 1 项base0 limit4G内核数据段选择子0x10GDT 第 2 项base0 limit4G时钟中断向量IRQ0328254 定时器触发用于 ticks 计数每 N 个 tick 打印TICK_NUM 100时钟处理里控制输出频率这张表里的每一条在后面章节我都会展开讲为什么是这个值。你先把它们当成路标看到的时候知道去哪找就行。3. bootloader 深度拆解从加电到保护模式3.1 bootasm.S 的启动序列与 A20上电那一刻 CPU 处在实模式寻址能力只有 1MB段寄存器参与地址计算的方式是段基址 × 16 偏移。BIOS 干完自己的初始化后会把硬盘第一扇区512 字节读进内存0x7C00然后跳过去执行。这 512 字节就是我们的 bootloader——bootasm.S加bootmain.c编出来的东西注意它必须塞进 512 字节这也是为什么 bootloader 只做最必要的事。bootasm.S一开头干的第一件事是关中断cli和清零方向标志cld然后清零ax、ds、es、ss这些段寄存器。为什么要在切保护模式前清段寄存器因为保护模式下段寄存器的含义完全变了你带着实模式残留的值跳过去会立刻触发异常。清零是为了让后面加载 GDT 时有个干净的起点。接着是开 A20。这个事挺有历史感——早期的 8086 只有 20 根地址线寻址到 1MB 就回绕。后来 80286 有了 24 根线为了兼容老程序物理上第 21 根线A20默认是关的你不开它超过 1MB 的访问还是会回绕到低地址。ucore 里通过键盘控制器来开 A20往0x64端口发命令0xD1再往0x60端口写数据0xDF把 A20 那一位置 1。写的代码大概是这样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那段testb $0x2循环是在等键盘控制器输入缓冲区空不等的话命令会丢。这是硬件时序问题不是逻辑问题新手经常漏掉这两段等待然后 A20 开不起来还找不到原因。3.2 GDT 与保护模式切换A20 开完就轮到 GDT全局描述符表。保护模式下的段寄存器不再是“基址”而是一个“选择子”它去 GDT 里查一个 8 字节的描述符描述符里记录着段的基址、限长和权限。ucore 定义了三项 GDT一个是全零的空描述符一个是代码段可读可执行、base 0、limit 4G一个是数据段可读写、base 0、limit 4G。在平坦内存模型下base 都是 0、limit 都是 4G 意味着段机制等于没限制后面地址转换直接交给分页。设置 GDT 之后把gdtdesc记录 GDT 长度和起始地址用lgdt加载进去然后置cr0的第 0 位movl %cr0, %eax orl $CR0_PE_ON, %eax movl %eax, %cr0 ljmp $PROT_MODE_CSEG, $protcseg关键在ljmp这条远跳转。光置 PE 位还不够CPU 要等下一次段寄存器加载才会真正按保护模式解析。这条长跳转把cs换成代码段选择子0x08同时刷新指令流水线从此进入 32 位世界。跳过来之后把数据段选择子0x10分别赋给ds、es、fs、gs、ss再设一个栈指针esp就能调 C 函数了。注意置 PE 位后如果不马上做远跳转后续指令仍按 16 位译码会读到错误的指令这是保护模式切换最经典的翻车点。练习 3 里让你分析这段就是要你说清楚“PE 位 远跳转”是成对出现的。我个人的体会是GDT 这段代码看着抽象但你把SEG_ASM宏展开看一眼就明白了它把 base、limit、权限位拼成一个 64 位的值。你可以手动算一遍代码段描述符的十六进制然后在 gdb 里x/2xw gdt对照验证自己真看懂了比死记硬背强得多。3.3 bootmain.c 解析 ELF 并跳入内核栈准备好之后会调用bootmain这是 C 写的引导逻辑核心任务只有一个把内核从硬盘读到内存然后跳进去。内核不是裸二进制而是 ELF 格式所以 bootmain 要做的就是解析 ELF 头、遍历程序头表、把每个段按它对8 的物理地址拷进内存。第一步读第一个扇区512 字节到内存里看它开头 4 个字节是不是0x464C457F\x7FELF的小端表示。是的话说明这是个合法 ELF接着从 ELF 头里取出程序头表的偏移和数量然后循环处理每个程序头for (i 0; i phnum; i, ph) { if (ph-p_type ! ELF_PT_LOAD) { continue; } readseg(ph-p_va 0xFFFFFF, ph-p_memsz, ph-p_offset); }注意那个 0xFFFFFF这就是前面说的虚拟地址转物理地址的技巧的简化版作用是把高地址的偏移抹掉得到真实的物理地址。每个段从硬盘读的时候用段在文件里的偏移p_offset和内存里的长度p_memsz。读完之后从 ELF 头里取入口地址强转成函数指针直接调用((void (*)(void))(ELFHDR-e_entry 0xFFFFFF))();这一跳就进了内核的kern_init。理解这段的要点在于ELF 头和程序头表的字段偏移都是固定的你不需要背实验里给的结构体定义看一眼就清楚。真正要理解的是“文件布局”和“内存布局”不是一回事p_offset是文件里的位置p_va是内存里的目标p_memsz可能比p_filesz大因为有 .bss 段那些字节在文件里不占空间但运行时要清零。提示练习 4 会问“bootmain 是如何判断它是 ELF 文件的、加载了几个段”。前一个问题答魔数判断后一个问题你可以在循环里加个计数器打印一下实测 ucore 内核通常有 3 到 4 个 LOAD 段具体以你构建出的镜像为准。4. 内核侧实操中断、堆栈与时钟4.1 堆栈跟踪函数 print_stackframe 的实现练习 5 要求实现print_stackframe这是个看着吓人其实逻辑很干净的函数。原理建立在 x86 的函数调用约定上每次调用一个函数call指令会先把返回地址压栈被调函数开头通常执行push %ebp; mov %esp, %ebp于是当前ebp指向的这块内存里偏移 0 处存的是调用者的ebp偏移 4 处存的是返回地址也就是当前函数的下一层调用点再往上偏移 8、12、16……是传进来的参数。所以回溯的过程就是从当前ebp出发读出eip返回地址和四个参数打出来然后让ebp *(uint32_t*)ebp跳到调用者的栈帧重复直到碰到栈底或者深度上限。代码大概是这样void print_stackframe(void) { uint32_t ebp read_ebp(); uint32_t eip read_eip(); int i, j; for (i 0; i STACKFRAME_DEPTH ebp ! 0; i ) { cprintf(ebp:0x%08x eip:0x%08x args:, ebp, eip); uint32_t *args (uint32_t *)ebp 2; for (j 0; j 4; j ) { cprintf(0x%08x , args[j]); } cprintf(\n); print_debuginfo(eip - 1); eip ((uint32_t *)ebp)[1]; ebp ((uint32_t *)ebp)[0]; } }read_ebp和read_eip是内联汇编直接mov %%ebp和mov %%eip到变量。为什么要eip - 1因为在call之后、被调函数push %ebp之前ebp里存的返回地址指向的是call的下一条指令而print_debuginfo是靠这个地址去查“这条地址属于哪个函数”所以得往回退一字节落到call指令内部才能正确定位到调用者。这个小细节不写出来打出来的函数名会是错位的。我踩过的一个坑是STACKFRAME_DEPTH设太大导致回溯到内核初始栈之后开始乱打因为栈底之外的内存没有有效栈帧。一般设 10 到 20 就够。还有ebp ! 0这个终止条件要加上不然某些情况下会死循环。这个函数写完你就拥有了一把调试内核的万能钥匙后面任何地方想看看“我是被谁调过来的”随手一句print_stackframe就有答案。4.2 IDT 初始化与中断分发主干练习 6 分两部分前半部分是把中断描述符表IDT初始化好。IDT 和 GDT 结构类似也是一张描述符表只不过每一项描述的是一个中断处理入口。x86 一共 256 个中断向量前 32 个是 CPU 保留的异常比如除零、缺页32 往后是外部设备中断。ucore 里用vectors.S生成了 256 个入口桩__vectors[]每个桩把对应向量号压栈然后跳到公共入口__alltraps。初始化函数要做的事是把__vectors[i]逐一填进 IDT 对应项用SETGATE宏设置权限级别。这里有个重点除了系统调用向量要设成用户态可访问DPL_USER其他中断都设成内核态DPL_KERNEL。为什么因为普通中断不该被用户程序主动触发设置成内核态可以防止用户态代码伪造中断进入内核执行。void idt_init(void) { extern uintptr_t __vectors[]; int i; for (i 0; i sizeof(idt) / sizeof(struct gatedesc); i ) { SETGATE(idt[i], 0, GD_KTEXT, __vectors[i], DPL_KERNEL); } SETGATE(idt[T_SYSCALL], 1, GD_KTEXT, __vectors[T_SYSCALL], DPL_USER); lidt(idt_pd); }填完之后lidt一下IDT 就生效了。中断发生后CPU 根据向量号查 IDT跳到对应的桩桩压入向量号跳到__alltraps。__alltraps在汇编里保存现场压入各类寄存器、段选择子然后调用 C 函数trap。trap再转给trap_dispatch由它根据向量号决定具体怎么处理。处理完返回trap再走__trapret恢复现场iret回到中断点。这条链要理解的关键点是“现场保存为什么必须用汇编”。因为 C 函数的调用本身就会改寄存器和栈中断来的时候你必须先把当时的完整寄存器状态原样存下来处理完再原样恢复否则中断一返回程序就崩了。trapframe这个结构体就是用来描述保存下来的现场布局的tf-tf_eip、tf-tf_regs.reg_eax这些字段后面会经常用到。注意SETGATE宏里有个istrap参数区分中断门和陷阱门。中断门会自动关中断陷阱门不会。时钟中断属于中断门因为处理期间不希望被同级中断打断而系统调用这种用陷阱门更合适。练习里如果问到了要能说清这两个的区别。4.3 时钟中断驱动的 ticks 计数与输出时钟中断是 Lab 1 最直观的部分让内核每过一段时间自动打印一条信息证明中断系统真的在工作。时钟源是 8254 定时器clock_init里配置它的频率让它周期性往 CPU 发 IRQ0。时钟中断的向量号是IRQ_OFFSET IRQ_TIMER在trap_dispatch里对应一个 casecase IRQ_OFFSET IRQ_TIMER: ticks ; if (ticks % TICK_NUM 0) { print_ticks(); } break;ticks是个全局计数每次时钟中断加一。TICK_NUM设为 100意味着每 100 次中断打印一次。这样你能看到内核每隔一小段时间输出一条100 ticks之类的信息说明中断在稳定触发。这里可以做一个有意思的小实验把TICK_NUM改成 10观察输出频率变快或者故意在时钟处理里加一个耗时操作看看会不会丢中断。这能帮你理解“中断处理应该尽量短”这条工程原则。时钟中断处理太长会挤占其他中断的响应时间严重时甚至导致系统看起来“卡住”。扩展练习一般会让你把时钟中断的处理延伸到用户态场景或者结合调度器做时间片轮转的雏形。虽然 Lab 1 阶段还没到进程调度但你可以先想清楚一个问题如果时钟中断里决定“要不要切换进程”那切换的时机和现场保存是怎么配合的。带着这个问题往后学Lab 4 会给你答案。我在配置时钟频率时踩过一个坑8254 的分频值算错了一位结果中断频率差了十倍打印输出快得刷屏。分频值的计算公式是频率 输入频率 / 分频值输入频率通常是 1193182 Hz想要 100Hz 就填约 11932。这种参数最好写在注释里免得过两天自己都忘了怎么来的。5. 常见问题与排查技巧实录5.1 启动阶段问题速查表做 Lab 1 时最高频的翻车点集中“启动就跑不起来”和“中断不进”两类我把它们整理成一张速查表遇到问题先对表能省不少时间。现象可能原因排查手段qemu 显示 “Booting from Hard Disk...” 后卡死bootloader 超过 512 字节魔数没写进去检查bootblock.out大小用xxd看最后两字节是否为 55 AAgdb 连上后跳到乱地址GDT 描述符写错或 PE 位后没远跳转在protcseg处下断点x/2xw gdt对照描述符内核能进但立刻异常栈指针 esp 没设或设到了非法地址在kern_init断点看 esp应在内核栈区域时钟中断一直不触发IDT 没lidt成功或 8254 没初始化断点打在trap_dispatch看有没有进来打印的调用栈函数名错位用了eip而不是eip - 1改print_debuginfo的入参make 后运行结果没变依赖关系错误kernel 没重新生成make clean后重来这张表里最值得说的是“bootloader 超 512 字节”这一条。因为引导扇区的限制是硬的你哪怕多写一个字符超了BIOS 只读前 512 字节剩下的丢掉魔数不在末尾就会直接被判为不可引导。所以 bootloader 里的 C 代码要精简复杂逻辑放内核。有一次我在bootmain.c里加了个调试打印结果整个镜像就起不来了排查半天才反应过来是超限。5.2 编译链接错误与段布局问题构建阶段的报错往往比运行阶段更让人抓狂因为信息量大。我总结了几类典型错误。第一类是 “undefined reference to xxx”一般是头文件包含不对或者函数名拼错仔细看报错里的函数名去源文件里搜就行。第二类是链接脚本相关的 “section overlaps” 或 “cannot find section”这通常是你往内核里加了新段但kernel.ld没相应调整或者目标文件顺序不对。第三类是 32/64 位不匹配的报错比如 “i386 architecture of input file is incompatible”这就是漏了-m32。内核链接地址这块还有个容易忽略的点Lab 1 阶段内核其实还是按物理地址0x100000在跑但因为链接脚本写的是0xC0100000bootmain 加载时要做地址转换。如果你改了链接脚本的起始地址务必要同步检查 bootmain 里的转换逻辑和后续任何直接用地址算偏移的地方。这种“链接地址”和“加载地址”不一致的设计是理解后续虚拟内存的前置知识别嫌它绕。提示改完链接脚本后用objdump -h bin/kernel看一下各段的 VMA虚拟地址和 LMA加载地址能直观看到两个地址体系的差别。这个命令我几乎每次改布局都会跑一遍。5.3 调试阶段的心得与避坑清单调试这块我有几条反复验证过的心得分享出来能让你少走弯路。第一善用print_stackframe和cprintf但别滥用内核里打印太频繁会拖慢中断响应、干扰时序最好配一个调试开关。第二gdb 里display/i $eip可以让每次停下来都自动显示当前指令单步汇编时特别顺手。第三碰到诡异崩溃先看cr2缺页地址和eflagsLab 1 阶段虽然没开分页但养成看这两个寄存器的习惯对后面有帮助。还有个项目管理的建议每完成一个练习就提交一次写清楚这次改了哪些文件、为什么。ucore 的练习之间有依赖你后面发现前面某处写错了需要回退时有清晰的提交记录能救命。我见过有人把所有练习攒在一起提交结果一个 bug 来回排查三天就是找不到是哪个改动引入的。最后说一个心态问题。Lab 1 的汇编部分会劝退不少人但你要记住bootloader 那几十行汇编是“一次性”的历史包袱看懂了原理之后后面几乎不用再手写这种代码。真正值钱的是它背后的保护模式、段机制、中断机制这些概念模型。把这些吃透你再看任何操作系统的启动流程都会有一种“原来如此”的通透感。6. 扩展练习与做完 Lab1 之后的复盘6.1 扩展练习该怎么下手Lab 1 的扩展练习通常有难度加成常见的是让你实现更完善的时钟中断处理或者深入理解陷阱处理的某个细节。我的建议是先把必做部分全部跑通、把每个回答的“为什么”都写扎实再动扩展。扩展不是炫技而是逼你把隐藏的机制想清楚。比如让你改中断处理来支持某种嵌套场景时你就要重新审视现场保存和恢复的顺序这个过程本身就是最好的学习。动手前先在纸上画出中断来临时栈的变化从用户态或内核态压入 eflags、cs、eip到桩压入向量号再到__alltraps压入一堆寄存器最后trapframe指针指向哪里。画一遍图你对tf里每个字段为什么在那个偏移就有了肌肉记忆。这个图我电脑上至今还留着一份做后面几个 Lab 时反复回看。6.2 做完 Lab1 我真正带走的东西回过头看Lab 1 教会我的不是某一段汇编怎么写而是一整套“自底向上理解系统”的方法遇到黑盒就单步进去看看不懂就画栈和内存布局图验证不了就打日志或下断点。这套方法在后来调试任何复杂系统时都好用。我的个人经验是Lab 1 里最容易被低估的是构建系统和调试环境这两块“脏活”。很多人觉得它们不算操作系统的核心草草了事结果后面每次都在这上面栽跟头。你如果能把 Makefile 的依赖关系理顺、把 gdb 调试脚本配顺手后面几个 Lab 的效率会明显不一样。相反环境问题带来的挫败感往往比技术难度本身更容易让人放弃。如果你做完这篇还觉得意犹未尽可以试着把内核启动到第一个 C 函数这条链路上的每一步都写一篇小笔记标注出每一条关键指令的意图。写的过程会逼你发现自己以为懂了其实没懂的细节。这种“教自己”的方式比刷十道题更能把知识焊进脑子里。
ucore Lab1：从 bootloader 到时钟中断全链路解析
1. 先搞清楚 ucore Lab1 在整门操作系统课里的位置1.1 这个实验到底让你做什么操作系统这门课最尴尬的地方在于课本上讲进程调度、虚拟内存、文件系统讲得头头是道可你合上书脑子里其实还是空的——因为你从来没真正看过一个操作系统从加电到跑起来的那几百行核心代码。ucore Lab 1 就是来填这个坑的。它不要求你从零手搓一个 OS而是给你一个已经能跑的最小内核骨架让你把“机器上电之后到底发生了什么”这条链路亲手走一遍。具体到 Lab 1你需要完成的动作可以概括成几个关键词看懂make是怎么把一堆.c、.S文件编译链接成一张可引导镜像的用 qemu 把这个镜像跑起来并用 gdb 接进去调试读懂 bootloader 怎么从实模式切到保护模式弄明白它怎么解析 ELF 格式把内核搬进内存最后还要动手实现一个堆栈回溯函数、把中断描述符表初始化完整、再让时钟中断每过 100 个 tick 打印一次提示。这一套下来你对“操作系统启动”这件事的理解会从“背概念”变成“真见过”。适合谁看这篇正在上操作系统实验课、被 ucore 的 Makefile 和汇编绕晕的同学想了解 x86 保护模式与中断机制但不想直接啃 Intel 手册的开发者以及准备考研 408 里操作系统部分想拿点真东西加深印象的人。哪怕你之前没碰过汇编只要肯跟着走Lab 1 的复杂度是可控的。1.2 为什么说 Lab1 是后面所有实验的地基我见过不少人做 Lab 1 的时候图省事直接把答案抄上去能跑通就交差结果到 Lab 2 物理内存管理、Lab 3 虚拟内存的时候整个人都是懵的。原因很简单后面所有实验都建立在“中断能正常进、内核能正常跑、栈能正常回溯”这三个前提上。Lab 1 没搞扎实后面每加一个功能都是往沙子上盖楼。拿中断来说Lab 1 里你把 IDT 填好、把__alltraps到trap这条路径打通后面 Lab 2 做页错误处理、Lab 3 做缺页异常、Lab 4 做系统调用走的都是同一套陷门机制只是把不同的中断向量挂上不同的处理函数。你要是 Lab 1 的trap_dispatch都没写明白后面遇到page fault只能干瞪眼。再比如堆栈回溯print_stackframe看着只是调试工具但它背后是函数调用约定ebp链这套硬知识你不理解栈帧布局后面调试任何内核崩溃都会抓瞎。所以我的建议是Lab 1 宁愿慢一点、把每个练习的“为什么”都写清楚也别急着往下赶。这一章的投入会在后面几章成倍地还给你。下面我就按我当年做实验的顺序把环境、构建、bootloader、中断这几块掰开揉碎讲一遍。2. 实验环境与构建链路从 make 到可引导镜像2.1 工具链准备与版本选择ucore 是个有点年头的教学项目对工具链版本比较敏感别上来就装最新版容易踩到莫名其妙的坑。我的建议是直接用 Ubuntu 18.04 或 20.04 这类比较稳的发行版或者干脆在虚拟机里跑省得污染你自己的开发机。需要的核心工具就几样gcc要能生成 32 位代码所以得装gcc-multilib、make、qemu-system-i386、gdb以及 binutils 里的objdump、objcopy、ld。这里有个新手常踩的坑现在很多机器是 64 位的默认gcc也是 64 位的但 ucore 编出来的是 32 位内核。你要么在 Makefile 里指定-m32要么确保装了 multilib 支持。实测下来最省事的做法是sudo apt install build-essential gcc-multilib qemu-system-i386 gdb。装完之后用qemu-system-i386 --version确认一下 qemu 能识别 32 位系统模拟。版本上有两个具体注意点。第一gcc 太新比如 10 以上对某些老代码的警告会升级成错误如果编译报一堆-Werror可以在 Makefile 里把-Werror去掉或者降级用 gcc-7 之类。第二qemu 版本太新时-kernel加载和-s -S调试接口的行为略有差异但基本兼容遇到问题优先看是不是参数写错了而不是怀疑版本。提示不要用 WSL1 做这个实验它的 gdb 与 qemu 协作经常出问题。WSL2 可以但调试端口转发要单独配新手建议直接上原生 Linux 或 VMware 里的 Ubuntu。2.2 ucore.img 是怎么一步步拼出来的这是练习 1 的核心。很多人第一次看 ucore 的 Makefile 会头大因为它有递归、有条件编译、有objcopy转角但你把链条画出来其实不复杂。最终目标是生成一张ucore.img这张镜像前 512 字节是 bootloader后面紧接着是内核 ELF。qemu 把它当成一块硬盘或者用-kernel直接加载从上电开始跑。我把构建的关键步骤列出来你可以对照 Makefile 里的目标看bootasm.S和bootmain.c先各自编译成.o再链接成bootblock.o用objcopy -O binary把bootblock.o抽成纯二进制bootblock.out再补上sign工具加的一个 0x55AA 魔数这是引导扇区的标志内核那一侧一堆.c和.S先编成.o用kernel.ld脚本链接成kernel最后用sign工具把bootblock和kernel拼接成ucore.img。这里kernel.ld是重点。它规定了内核代码从哪个虚拟地址开始放。ucore 里内核链接地址是0xC0100000但物理加载地址是0x1000001MB。为什么要差这0xC0000000因为 ucore 后面要做虚拟内存把内核映射到高地址区那个偏移量是给分页机制留的。Lab 1 阶段虽然还没开分页但链接脚本已经按这个约定写好了bootmain 加载 ELF 时也要把程序头里记录的虚拟地址减掉这个偏移算回真实的物理地址再拷贝。注意练习 1 通常会让你回答“bootblock 和 kernel 分别被加载到哪个地址、为什么”。答案要落到0x7c00bootloader 被 BIOS 加载的位置和0x100000内核物理加载位置这两个数上别只写个大概。理解这条链条的意义在于以后你改任何内核代码都要清楚它最终是怎么进入镜像、又是怎么被加载的。有一次我改了个内核函数结果运行没变化排查半天才发现是make没有重新生成kernel因为依赖关系被我用一个错误的写法破坏了。构建系统这东西你以为它理所当然其实很容易出问题。2.3 qemu 启动与 GDB 双机调试接入镜像有了接下来是跑起来和调试。启动命令一般长这样qemu-system-i386 -hda bin/ucore.img -monitor stdio -s -S-s是-gdb tcp::1234的简写意思是 qemu 开一个 gdb server 监听 1234 端口并冻结 CPU 等待调试器接入-S表示启动时先暂停。然后你另开一个终端gdb bin/kernel (gdb) target remote :1234 (gdb) b kern_init (gdb) c这样就能在内核入口处断下来。我强烈建议你在bootasm.S开头、bootmain入口、kern_init三处都下断点单步走一遍感受从 16 位实模式到 32 位保护模式的切换过程。看寄存器cr0的 PE 位从 0 变 1 那一刻比看十页课本都直观。调试时有个小技巧qemu 冻结在-S状态时用info registers看到的还是实模式寄存器。等你si单步过保护模式切换那几条指令之后再info registers就会看到 32 位寄存器段选择子变成 0x8、0x10 这种。这一步是验证你 GDT 写对没有的最快方法。提示gdb 里x/10i $eip反汇编当前位置的指令非常有用配合si单步你会看到保护模式切换前后的指令编码长度都不一样16 位和 32 位指令前缀不同。2.4 一张表理清关键地址与端口实验里涉及不少魔数初学时容易记混我整理了一张表贴在显示器旁边会省很多回翻文档的时间。名称数值/端口作用说明引导扇区加载地址0x7C00BIOS 把第一扇区搬到内存的位置内核物理加载地址0x1000001MB 处bootmain 把 ELF 段拷到这里内核链接虚拟地址0xC0100000链接脚本约定的高地址A20 使能端口0x64/0x60键盘控制器置位第 2 位打开 A20CR0 PE 位bit 0置 1 进入保护模式内核代码段选择子0x08GDT 第 1 项base0 limit4G内核数据段选择子0x10GDT 第 2 项base0 limit4G时钟中断向量IRQ0328254 定时器触发用于 ticks 计数每 N 个 tick 打印TICK_NUM 100时钟处理里控制输出频率这张表里的每一条在后面章节我都会展开讲为什么是这个值。你先把它们当成路标看到的时候知道去哪找就行。3. bootloader 深度拆解从加电到保护模式3.1 bootasm.S 的启动序列与 A20上电那一刻 CPU 处在实模式寻址能力只有 1MB段寄存器参与地址计算的方式是段基址 × 16 偏移。BIOS 干完自己的初始化后会把硬盘第一扇区512 字节读进内存0x7C00然后跳过去执行。这 512 字节就是我们的 bootloader——bootasm.S加bootmain.c编出来的东西注意它必须塞进 512 字节这也是为什么 bootloader 只做最必要的事。bootasm.S一开头干的第一件事是关中断cli和清零方向标志cld然后清零ax、ds、es、ss这些段寄存器。为什么要在切保护模式前清段寄存器因为保护模式下段寄存器的含义完全变了你带着实模式残留的值跳过去会立刻触发异常。清零是为了让后面加载 GDT 时有个干净的起点。接着是开 A20。这个事挺有历史感——早期的 8086 只有 20 根地址线寻址到 1MB 就回绕。后来 80286 有了 24 根线为了兼容老程序物理上第 21 根线A20默认是关的你不开它超过 1MB 的访问还是会回绕到低地址。ucore 里通过键盘控制器来开 A20往0x64端口发命令0xD1再往0x60端口写数据0xDF把 A20 那一位置 1。写的代码大概是这样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那段testb $0x2循环是在等键盘控制器输入缓冲区空不等的话命令会丢。这是硬件时序问题不是逻辑问题新手经常漏掉这两段等待然后 A20 开不起来还找不到原因。3.2 GDT 与保护模式切换A20 开完就轮到 GDT全局描述符表。保护模式下的段寄存器不再是“基址”而是一个“选择子”它去 GDT 里查一个 8 字节的描述符描述符里记录着段的基址、限长和权限。ucore 定义了三项 GDT一个是全零的空描述符一个是代码段可读可执行、base 0、limit 4G一个是数据段可读写、base 0、limit 4G。在平坦内存模型下base 都是 0、limit 都是 4G 意味着段机制等于没限制后面地址转换直接交给分页。设置 GDT 之后把gdtdesc记录 GDT 长度和起始地址用lgdt加载进去然后置cr0的第 0 位movl %cr0, %eax orl $CR0_PE_ON, %eax movl %eax, %cr0 ljmp $PROT_MODE_CSEG, $protcseg关键在ljmp这条远跳转。光置 PE 位还不够CPU 要等下一次段寄存器加载才会真正按保护模式解析。这条长跳转把cs换成代码段选择子0x08同时刷新指令流水线从此进入 32 位世界。跳过来之后把数据段选择子0x10分别赋给ds、es、fs、gs、ss再设一个栈指针esp就能调 C 函数了。注意置 PE 位后如果不马上做远跳转后续指令仍按 16 位译码会读到错误的指令这是保护模式切换最经典的翻车点。练习 3 里让你分析这段就是要你说清楚“PE 位 远跳转”是成对出现的。我个人的体会是GDT 这段代码看着抽象但你把SEG_ASM宏展开看一眼就明白了它把 base、limit、权限位拼成一个 64 位的值。你可以手动算一遍代码段描述符的十六进制然后在 gdb 里x/2xw gdt对照验证自己真看懂了比死记硬背强得多。3.3 bootmain.c 解析 ELF 并跳入内核栈准备好之后会调用bootmain这是 C 写的引导逻辑核心任务只有一个把内核从硬盘读到内存然后跳进去。内核不是裸二进制而是 ELF 格式所以 bootmain 要做的就是解析 ELF 头、遍历程序头表、把每个段按它对8 的物理地址拷进内存。第一步读第一个扇区512 字节到内存里看它开头 4 个字节是不是0x464C457F\x7FELF的小端表示。是的话说明这是个合法 ELF接着从 ELF 头里取出程序头表的偏移和数量然后循环处理每个程序头for (i 0; i phnum; i, ph) { if (ph-p_type ! ELF_PT_LOAD) { continue; } readseg(ph-p_va 0xFFFFFF, ph-p_memsz, ph-p_offset); }注意那个 0xFFFFFF这就是前面说的虚拟地址转物理地址的技巧的简化版作用是把高地址的偏移抹掉得到真实的物理地址。每个段从硬盘读的时候用段在文件里的偏移p_offset和内存里的长度p_memsz。读完之后从 ELF 头里取入口地址强转成函数指针直接调用((void (*)(void))(ELFHDR-e_entry 0xFFFFFF))();这一跳就进了内核的kern_init。理解这段的要点在于ELF 头和程序头表的字段偏移都是固定的你不需要背实验里给的结构体定义看一眼就清楚。真正要理解的是“文件布局”和“内存布局”不是一回事p_offset是文件里的位置p_va是内存里的目标p_memsz可能比p_filesz大因为有 .bss 段那些字节在文件里不占空间但运行时要清零。提示练习 4 会问“bootmain 是如何判断它是 ELF 文件的、加载了几个段”。前一个问题答魔数判断后一个问题你可以在循环里加个计数器打印一下实测 ucore 内核通常有 3 到 4 个 LOAD 段具体以你构建出的镜像为准。4. 内核侧实操中断、堆栈与时钟4.1 堆栈跟踪函数 print_stackframe 的实现练习 5 要求实现print_stackframe这是个看着吓人其实逻辑很干净的函数。原理建立在 x86 的函数调用约定上每次调用一个函数call指令会先把返回地址压栈被调函数开头通常执行push %ebp; mov %esp, %ebp于是当前ebp指向的这块内存里偏移 0 处存的是调用者的ebp偏移 4 处存的是返回地址也就是当前函数的下一层调用点再往上偏移 8、12、16……是传进来的参数。所以回溯的过程就是从当前ebp出发读出eip返回地址和四个参数打出来然后让ebp *(uint32_t*)ebp跳到调用者的栈帧重复直到碰到栈底或者深度上限。代码大概是这样void print_stackframe(void) { uint32_t ebp read_ebp(); uint32_t eip read_eip(); int i, j; for (i 0; i STACKFRAME_DEPTH ebp ! 0; i ) { cprintf(ebp:0x%08x eip:0x%08x args:, ebp, eip); uint32_t *args (uint32_t *)ebp 2; for (j 0; j 4; j ) { cprintf(0x%08x , args[j]); } cprintf(\n); print_debuginfo(eip - 1); eip ((uint32_t *)ebp)[1]; ebp ((uint32_t *)ebp)[0]; } }read_ebp和read_eip是内联汇编直接mov %%ebp和mov %%eip到变量。为什么要eip - 1因为在call之后、被调函数push %ebp之前ebp里存的返回地址指向的是call的下一条指令而print_debuginfo是靠这个地址去查“这条地址属于哪个函数”所以得往回退一字节落到call指令内部才能正确定位到调用者。这个小细节不写出来打出来的函数名会是错位的。我踩过的一个坑是STACKFRAME_DEPTH设太大导致回溯到内核初始栈之后开始乱打因为栈底之外的内存没有有效栈帧。一般设 10 到 20 就够。还有ebp ! 0这个终止条件要加上不然某些情况下会死循环。这个函数写完你就拥有了一把调试内核的万能钥匙后面任何地方想看看“我是被谁调过来的”随手一句print_stackframe就有答案。4.2 IDT 初始化与中断分发主干练习 6 分两部分前半部分是把中断描述符表IDT初始化好。IDT 和 GDT 结构类似也是一张描述符表只不过每一项描述的是一个中断处理入口。x86 一共 256 个中断向量前 32 个是 CPU 保留的异常比如除零、缺页32 往后是外部设备中断。ucore 里用vectors.S生成了 256 个入口桩__vectors[]每个桩把对应向量号压栈然后跳到公共入口__alltraps。初始化函数要做的事是把__vectors[i]逐一填进 IDT 对应项用SETGATE宏设置权限级别。这里有个重点除了系统调用向量要设成用户态可访问DPL_USER其他中断都设成内核态DPL_KERNEL。为什么因为普通中断不该被用户程序主动触发设置成内核态可以防止用户态代码伪造中断进入内核执行。void idt_init(void) { extern uintptr_t __vectors[]; int i; for (i 0; i sizeof(idt) / sizeof(struct gatedesc); i ) { SETGATE(idt[i], 0, GD_KTEXT, __vectors[i], DPL_KERNEL); } SETGATE(idt[T_SYSCALL], 1, GD_KTEXT, __vectors[T_SYSCALL], DPL_USER); lidt(idt_pd); }填完之后lidt一下IDT 就生效了。中断发生后CPU 根据向量号查 IDT跳到对应的桩桩压入向量号跳到__alltraps。__alltraps在汇编里保存现场压入各类寄存器、段选择子然后调用 C 函数trap。trap再转给trap_dispatch由它根据向量号决定具体怎么处理。处理完返回trap再走__trapret恢复现场iret回到中断点。这条链要理解的关键点是“现场保存为什么必须用汇编”。因为 C 函数的调用本身就会改寄存器和栈中断来的时候你必须先把当时的完整寄存器状态原样存下来处理完再原样恢复否则中断一返回程序就崩了。trapframe这个结构体就是用来描述保存下来的现场布局的tf-tf_eip、tf-tf_regs.reg_eax这些字段后面会经常用到。注意SETGATE宏里有个istrap参数区分中断门和陷阱门。中断门会自动关中断陷阱门不会。时钟中断属于中断门因为处理期间不希望被同级中断打断而系统调用这种用陷阱门更合适。练习里如果问到了要能说清这两个的区别。4.3 时钟中断驱动的 ticks 计数与输出时钟中断是 Lab 1 最直观的部分让内核每过一段时间自动打印一条信息证明中断系统真的在工作。时钟源是 8254 定时器clock_init里配置它的频率让它周期性往 CPU 发 IRQ0。时钟中断的向量号是IRQ_OFFSET IRQ_TIMER在trap_dispatch里对应一个 casecase IRQ_OFFSET IRQ_TIMER: ticks ; if (ticks % TICK_NUM 0) { print_ticks(); } break;ticks是个全局计数每次时钟中断加一。TICK_NUM设为 100意味着每 100 次中断打印一次。这样你能看到内核每隔一小段时间输出一条100 ticks之类的信息说明中断在稳定触发。这里可以做一个有意思的小实验把TICK_NUM改成 10观察输出频率变快或者故意在时钟处理里加一个耗时操作看看会不会丢中断。这能帮你理解“中断处理应该尽量短”这条工程原则。时钟中断处理太长会挤占其他中断的响应时间严重时甚至导致系统看起来“卡住”。扩展练习一般会让你把时钟中断的处理延伸到用户态场景或者结合调度器做时间片轮转的雏形。虽然 Lab 1 阶段还没到进程调度但你可以先想清楚一个问题如果时钟中断里决定“要不要切换进程”那切换的时机和现场保存是怎么配合的。带着这个问题往后学Lab 4 会给你答案。我在配置时钟频率时踩过一个坑8254 的分频值算错了一位结果中断频率差了十倍打印输出快得刷屏。分频值的计算公式是频率 输入频率 / 分频值输入频率通常是 1193182 Hz想要 100Hz 就填约 11932。这种参数最好写在注释里免得过两天自己都忘了怎么来的。5. 常见问题与排查技巧实录5.1 启动阶段问题速查表做 Lab 1 时最高频的翻车点集中“启动就跑不起来”和“中断不进”两类我把它们整理成一张速查表遇到问题先对表能省不少时间。现象可能原因排查手段qemu 显示 “Booting from Hard Disk...” 后卡死bootloader 超过 512 字节魔数没写进去检查bootblock.out大小用xxd看最后两字节是否为 55 AAgdb 连上后跳到乱地址GDT 描述符写错或 PE 位后没远跳转在protcseg处下断点x/2xw gdt对照描述符内核能进但立刻异常栈指针 esp 没设或设到了非法地址在kern_init断点看 esp应在内核栈区域时钟中断一直不触发IDT 没lidt成功或 8254 没初始化断点打在trap_dispatch看有没有进来打印的调用栈函数名错位用了eip而不是eip - 1改print_debuginfo的入参make 后运行结果没变依赖关系错误kernel 没重新生成make clean后重来这张表里最值得说的是“bootloader 超 512 字节”这一条。因为引导扇区的限制是硬的你哪怕多写一个字符超了BIOS 只读前 512 字节剩下的丢掉魔数不在末尾就会直接被判为不可引导。所以 bootloader 里的 C 代码要精简复杂逻辑放内核。有一次我在bootmain.c里加了个调试打印结果整个镜像就起不来了排查半天才反应过来是超限。5.2 编译链接错误与段布局问题构建阶段的报错往往比运行阶段更让人抓狂因为信息量大。我总结了几类典型错误。第一类是 “undefined reference to xxx”一般是头文件包含不对或者函数名拼错仔细看报错里的函数名去源文件里搜就行。第二类是链接脚本相关的 “section overlaps” 或 “cannot find section”这通常是你往内核里加了新段但kernel.ld没相应调整或者目标文件顺序不对。第三类是 32/64 位不匹配的报错比如 “i386 architecture of input file is incompatible”这就是漏了-m32。内核链接地址这块还有个容易忽略的点Lab 1 阶段内核其实还是按物理地址0x100000在跑但因为链接脚本写的是0xC0100000bootmain 加载时要做地址转换。如果你改了链接脚本的起始地址务必要同步检查 bootmain 里的转换逻辑和后续任何直接用地址算偏移的地方。这种“链接地址”和“加载地址”不一致的设计是理解后续虚拟内存的前置知识别嫌它绕。提示改完链接脚本后用objdump -h bin/kernel看一下各段的 VMA虚拟地址和 LMA加载地址能直观看到两个地址体系的差别。这个命令我几乎每次改布局都会跑一遍。5.3 调试阶段的心得与避坑清单调试这块我有几条反复验证过的心得分享出来能让你少走弯路。第一善用print_stackframe和cprintf但别滥用内核里打印太频繁会拖慢中断响应、干扰时序最好配一个调试开关。第二gdb 里display/i $eip可以让每次停下来都自动显示当前指令单步汇编时特别顺手。第三碰到诡异崩溃先看cr2缺页地址和eflagsLab 1 阶段虽然没开分页但养成看这两个寄存器的习惯对后面有帮助。还有个项目管理的建议每完成一个练习就提交一次写清楚这次改了哪些文件、为什么。ucore 的练习之间有依赖你后面发现前面某处写错了需要回退时有清晰的提交记录能救命。我见过有人把所有练习攒在一起提交结果一个 bug 来回排查三天就是找不到是哪个改动引入的。最后说一个心态问题。Lab 1 的汇编部分会劝退不少人但你要记住bootloader 那几十行汇编是“一次性”的历史包袱看懂了原理之后后面几乎不用再手写这种代码。真正值钱的是它背后的保护模式、段机制、中断机制这些概念模型。把这些吃透你再看任何操作系统的启动流程都会有一种“原来如此”的通透感。6. 扩展练习与做完 Lab1 之后的复盘6.1 扩展练习该怎么下手Lab 1 的扩展练习通常有难度加成常见的是让你实现更完善的时钟中断处理或者深入理解陷阱处理的某个细节。我的建议是先把必做部分全部跑通、把每个回答的“为什么”都写扎实再动扩展。扩展不是炫技而是逼你把隐藏的机制想清楚。比如让你改中断处理来支持某种嵌套场景时你就要重新审视现场保存和恢复的顺序这个过程本身就是最好的学习。动手前先在纸上画出中断来临时栈的变化从用户态或内核态压入 eflags、cs、eip到桩压入向量号再到__alltraps压入一堆寄存器最后trapframe指针指向哪里。画一遍图你对tf里每个字段为什么在那个偏移就有了肌肉记忆。这个图我电脑上至今还留着一份做后面几个 Lab 时反复回看。6.2 做完 Lab1 我真正带走的东西回过头看Lab 1 教会我的不是某一段汇编怎么写而是一整套“自底向上理解系统”的方法遇到黑盒就单步进去看看不懂就画栈和内存布局图验证不了就打日志或下断点。这套方法在后来调试任何复杂系统时都好用。我的个人经验是Lab 1 里最容易被低估的是构建系统和调试环境这两块“脏活”。很多人觉得它们不算操作系统的核心草草了事结果后面每次都在这上面栽跟头。你如果能把 Makefile 的依赖关系理顺、把 gdb 调试脚本配顺手后面几个 Lab 的效率会明显不一样。相反环境问题带来的挫败感往往比技术难度本身更容易让人放弃。如果你做完这篇还觉得意犹未尽可以试着把内核启动到第一个 C 函数这条链路上的每一步都写一篇小笔记标注出每一条关键指令的意图。写的过程会逼你发现自己以为懂了其实没懂的细节。这种“教自己”的方式比刷十道题更能把知识焊进脑子里。
)
