这学期的操作系统课做到 lab4，我盯着题目列表愣了好一会儿——一段 RISC-V 汇编问答、一个栈回溯、一个定时闹钟。如果只看名字，这三件事像是互相独立的小作业，但做完之后回头看就会发现，它们其实是同一个问题的三个阶段：用户进程到底是怎么被内核打断，又怎么在打断之后完好无损地回到原来的执行现场。这篇东西就是我完成 xv6 lab4（traps 实验）之后的完整复盘，包含解题思路、关键代码和几次差点让人怀疑人生的调试经历。不同课程对 lab4 的编号和内容不完全一样，但我这里做的是 xv6 经典系列里的 traps 实验；如果你也是正在写操作系统实验报告，或者对 RISC-V 的 trap 机制只有一个模糊印象，这份内容应该能让你少走几条弯路。
1. 先别急着改代码：lab4 到底在考察什么
1.1 从 lab1 到 lab4，一条完整的"权限切换"主线
很多同学做 xv6 系列实验时，会把每个 lab 当成独立关卡：lab1 写几个用户程序，lab2 加两个系统调用，lab3 折腾页表，lab4 又开始搞汇编。这样一个个通过其实没错，但会错过一条暗线——从 lab1 到 lab4，xv6 是在让你逐步看清一次系统调用背后要穿过多少层防线。
lab1 和 lab2 只是站在用户态调用，内核态的处理逻辑对调用者完全透明；lab3 开始接触页表，你知道了用户地址和内核地址不是同一个世界；到 lab4，内核终于把"权限切换"这件事完全摊开：当用户进程执行ecall指令、遇到异常、或者收到时钟中断时，CPU 会从用户态一脚踏进内核态，经由 trampoline 跳到内核的 trap 处理入口，用 trapframe 存下现场，处理完再从 trapframe 恢复现场并返回用户态。
traps 实验的三道题，就是围绕这条主线的三次由浅入深。汇编问答是热身，考察你对 RISC-V 寄存器约定和编译结果的基本感觉；backtrace 让你顺着栈帧回溯调用链，本质是理解"现场"在内存里长什么样；alarm 则要求你主动劫持一次时钟中断，把流程引到用户自定义的 handler 上，再原样恢复现场，等价于实现一个极简版的"信号"机制。
所以写实验报告时，我不建议把三道题分别回答完就收工。更好的组织方式是：先讲清楚 trap 机制的整体路径，再说明每个题目分别补全了路径上的哪一块。这样读者一眼就能看出你不是在抄代码，而是真的理解了这套机制。
1.2 实验环境与源码结构速览
我这次用的环境是 xv6-riscv 源码加 qemu 模拟器，配合 RISC-V 64 位工具链，编译和运行都是老一套：make qemu进入系统，make grade跑评分脚本。源码里需要重点关注的文件有这几个：
kernel/trap.c：中断和异常的统一入口 usertrap，以及时钟中断的处理分支；kernel/sysproc.c：sys_sigalarm 和 sys_sigreturn 两个系统调用的实现位置；kernel/proc.h：进程结构体，需要给它扩展闹钟相关字段；kernel/printf.c：backtrace 的实现位置，题目要求在sys_sleep里调用它；user/alarmtest.c：闹钟实验的测试程序，包含 test0/test1/test2 三个阶段。
如果你之前没注意过kernel/trampoline.S和kernel/trapframe.h，这个实验最好先打开看一眼。trampoline 是用户态和内核态切换的第一段汇编代码，它保证即使页表被换掉，这段代码仍然同时映射在用户地址空间最高页和内核地址空间最高页；trapframe 则是每个进程在用户地址空间里预留下的一块内存，用于存取所有寄存器的快照。理解了这两样东西，后面看 alarm 实验为什么要保存一个独立的 trapframe 副本，就会顺理成章。
1.3 三个绕不开的概念：trapframe、trampoline 与 kernelvec
实验报告里最容易被忽略、但我认为最该写清楚的是这三个概念的分工。
trapframe 是每个进程独立拥有的一块结构体，里面从 ra、sp 到所有通用寄存器、sstatus、epc 都被记录在案。用户态代码不需要知道它的存在，但内核每次从用户态陷入时，都会先把寄存器的值存进去，返回时再从里面取出来，从而保证用户程序的现场丝毫无损。
trampoline 是一段被"双映射"的代码，同时出现在用户页表最高页和内核页表最高页。为什么不能只映射一份？因为从用户陷入内核时需要换页表，如果 trampoline 不在新页表里，换完页表后 CPU 就会因为取不到下一条指令而崩溃。双映射解决的就是这个"换挡瞬间不能断油"的问题。
kernelvec 是内核态异常入口。用户态的 trap 经过 trampoline 后会走到它，它做的事情很朴素：把当前内核栈指针、寄存器保存好，然后调用 usertrap 进入 C 语言世界。你可以把这条路径想象成：用户在家里（用户态）处理正事，突然收到一个通知，通过 trampoline 这条公共走廊溜进公司（内核态），在 trapframe 这个储物柜里存好随身物品，然后由 kernelvec 前台带去见 usertrap 经理。整个 lab4，你实际上就是在跟这条路径打交道。
2. Backtrace：用 RISC-V 栈帧布局做一次"寻亲"
2.1 为什么要做栈回溯：崩溃时最需要知道"谁叫我来的"
系统卡死或 panic 时，打印出当前程序计数器只能告诉我"我在哪里"，但没法告诉我"我是怎么到这里来的"。栈回溯要做的事，就是沿着函数调用链一层层往上找，把所有尚未返回的调用点（return address）都打出来。调试器里常见的 call stack 就是这样实现的。
xv6 的 backtrace 题要求：在kernel/printf.c里实现一个backtrace()，并在sys_sleep中调用它，让它在控制台打印出调用链上的返回地址。看起来很简单，但如果你不理解 RISC-V 的栈帧布局，可能会把指针算错，打印出一堆乱码，甚至直接把内核搞崩溃。
2.2 RISC-V 栈帧布局：fp、ra、sp 三者的关系
先复习一下 x86 会更容易抓住要点。x86 的传统栈帧用rbp做 frame pointer，返回地址通常保存在rbp + 8，前一个栈帧的rbp保存在rbp指向的位置。RISC-V 的约定略有不同：按编译器默认布局，每个非叶函数的栈帧里，返回地址保存在当前帧的fp - 8偏移处，上一帧的 fp 保存在fp - 16偏移处。
这个布局是编译器和 ABI 共同约定的，不是 CPU 硬件强制要求的。大致可以画成这样（基于 gcc 对 RISC-V 的常见生成结果）：
高地址 +------------------+ | caller 的栈帧 | +------------------+ | 返回地址 | <- fp - 8 | 上一帧 fp | <- fp - 16 | 本函数局部变量 | <- fp +------------------+ 低地址这里的 fp 一般会映射到寄存器s0。所以回溯的思路很直接：拿到当前s0作为 fp，读fp - 8得到返回地址，读fp - 16得到上一帧 fp，然后让 fp 等于上一帧 fp，继续循环，直到到达栈的边界。
边界判断是这道题最容易忽略的细节。用户态的栈从USTACKTOP（也就是MAXVA - PGSIZE）往低地址生长，内核栈类似，也是一页往低地址生长。遍历时如果发现 fp 落在[PGSIZE, MAXVA)区间之外，就可以认为栈链已经结束，或者栈已经被破坏，此时应当停止，否则可能去读一个完全无效的地址，触发缺页异常。很多同学写while (fp != USTACKTOP)，这种方式在特殊首帧情况下可以工作，但遇到栈被破坏或边界不理想时会死循环，不如用区间判断更稳。
2.3 代码落地的完整过程与边界判断
实现方式我分三步来写。
第一步，需要一个读取 fp（s0）的辅助函数。这个函数不能直接用 C 变量去拿 s0，因为 C 变量在栈上，s0 是寄存器。最可靠的做法是用内联汇编：
static inline uint64 r_fp(void) { uint64 x; asm volatile("mv %0, s0" : "=r" (x)); return x; }第二步，在kernel/printf.c里实现backtrace()：
void backtrace(void) { uint64 fp = r_fp(); uint64 ra; printf("backtrace:\n"); while (fp >= PGSIZE && fp < MAXVA) { ra = *(uint64 *)(fp - 8); printf("%p\n", ra); fp = *(uint64 *)(fp - 16); } }这里有个顺序上的小细节：不要在循环里先改 fp 再打印 ra，因为printf会创建自己的栈帧，虽然它用的是自己的 fp，但不影响我们已经保存在局部变量里的 fp。先把 ra 和下一次 fp 读出来，再调用 printf，逻辑上更安全，也不会被 printf 内部的栈操作干扰。
第三步，按题目要求调用它。xv6 标准做法是在sys_sleep开头加一行：
uint64 sys_sleep(void) { int n; uint ticks0; ... backtrace(); // 实验验证用，真实系统不会在 sleep 里回溯 ... }有的同学想直接在panic里调用backtrace，这其实更有价值——拿到的调用链能直接指出 panic 发生在哪一层。不过实验要求明确，我建议先按要求实现，在实验报告里再提一句"生产环境更适合放在 panic 或异常处理中"，反而显得有思考。
2.4 验证：跑一次真实的调用链
在 qemu 里随便运行一个会触发 sleep 的程序，比如执行sleep 1，如果实现正确，终端会打印一串地址。要验证这些地址确实是调用链上的返回地址，最干净的办法是用 qemu 的 gdb 支持：make qemu-gdb启动带调试的 qemu，再用 gdb 连接，在sys_sleep打断点，打印当前 fp 附近的字段，确认与代码输出一致。
我在实验报告里通常会把一次输出样例贴出来，并注解每一行的含义：最下面一般是sys_sleep的调用点，往上能看到syscall、usertrap的帧，直到链结束。这样报告读起来就不是空洞的"我实现了 backtrace"，而是"我知道它为什么输出这几行"。
3. 闹钟实验：让内核在指定时刻"温柔地打断"用户进程
3.1 三道测试题的递进关系
alarm 实验先给出一个测试程序alarmtest.c，里面包含三个阶段的要求。我建议大家不要急着开写，先用十分钟读懂这三个测试分别想卡住什么。
test0 是最朴素的闹钟：用户进程调用sigalarm(interval, handler)注册一个定时回调，主程序每过段时间检查计数器。期望结果是每隔 interval 个时钟 tick，handler 被调用一次，主程序从被打断的地方继续往下走。这一步考察的是基本"劫持-恢复"流程。
test1 增加了重入检查：它让 handler 执行时间很长，里面循环等若干 ticks，如果内核在 handler 还没返回时又触发了一次新的 handler，就会导致深度递归、栈溢出。期望结果是 handler 执行期间，新到达的闹钟不得再次进入 handler。
test2 更进一步，handler 内部还调用了write等系统调用。听起来无非是更复杂的执行路径，但它真正考验的是：你保存的"原现场"会不会被 handler 自身的系统调用给冲掉。如果保存现场时没有用独立空间，或者恢复时机不对，后面的调用链就会全乱。
所以这道题不是简单地在中断里跳个转，而是要把"定时计数、现场保存、防止重入、恢复现场"四个环节全部做对。
3.2 进程结构体扩展与 sys_sigalarm 的实现
动手改代码前，先确认系统调用怎么注册。在kernel/syscall.h里新增两个编号，在kernel/syscall.c里把sys_sigalarm、sys_sigreturn挂到对应位置，同时在user/user.h里声明用户态函数。这些都是机械操作，如果遗漏，测试程序会报"unknown sys call"。
接着给proc结构体加四个字段，都在kernel/proc.h里：
struct proc { ... int alarm_interval; // 多少 ticks 触发一次，0 表示关闭 uint64 alarm_handler; // 用户态 handler 的虚拟地址 int alarm_ticks; // 距上次触发已走过的 ticks int alarm_handler_active; // 1 表示当前正处于 handler 中 struct trapframe alarm_saved_trapframe; // 进入 handler 前的完整现场 };这里有一个关键选择：保存现场用struct trapframe类型的内嵌变量，而不是一个指针。为什么不用指针？因为指针通常会指向p->trapframe，而每次用户陷入内核时，硬件和 trampoline 都会往p->trapframe里写当前寄存器值。也就是说，trapframe 本身就是一块每陷入一次就刷新一次的内存。若用指针指向它，等 handler 跑了一会儿之后再想恢复"进入 handler 前的现场"，读到的可能早已是新的 trapframe 了。独立的alarm_saved_trapframe是一份只在我们主动保存的时刻写一次的副本，不会被后续系统调用覆盖。代价是每个进程多占一点内存，但对教学内核可以接受。
sys_sigalarm的实现则比较直接：
uint64 sys_sigalarm(void) { int interval; uint64 handler; struct proc *p = myproc(); if (argint(0, &interval) < 0 || argaddr(1, &handler) < 0) return -1; p->alarm_interval = interval; p->alarm_handler = handler; p->alarm_ticks = 0; return 0; }这里值得在实验报告里解释的是：argint和argaddr是 xv6 提供的参数读取接口，它们会从当前进程的 trapframe 里取出用户传入的 a0/a1 寄存器值。用户传入的是用户态的值，不能直接把它当内核指针去解引用。interval 为 0 时，usertrap 里的判断会直接跳过触发逻辑，这就实现了sigalarm(0, 0)的关闭语义。
3.3 usertrap 中的跳转逻辑：保存现场与修改 epc
真正的核心逻辑在kernel/trap.c的usertrap里。xv6 原本的时钟中断分支大致是：
if (which_dev == 2) { yield(); }yield 会切换进程，等这个进程再次被调度回来时，trapframe 里记录的还是陷入时的现场，CPU 会从原来的 pc 处继续执行。我们要做的，是在这个分支里插入一段"劫持"逻辑：
if (which_dev == 2) { if (p->alarm_interval > 0) { p->alarm_ticks += 1; if (p->alarm_ticks >= p->alarm_interval) { p->alarm_ticks = 0; if (p->alarm_handler_active == 0) { // 保存当前陷入现场的完整副本 *p->alarm_saved_trapframe = *p->trapframe; // 修改返回地址，让用户态下一条指令变成 handler p->trapframe->epc = p->alarm_handler; p->alarm_handler_active = 1; } } } yield(); }为什么是修改epc，而不是修改ra？epc（exception program counter）是返回用户态时 CPU 恢复执行的指令地址，trampoline 的userret会把它写回sepc，再通过sret返回。handler 本质上就是一个用户态函数，只要让 epc 指向它，下一次返回用户态时，CPU 自然会执行 handler 的第一条指令。用户态的栈指针 sp 不需要改，因为 handler 和主程序共享同一个用户栈，handler 按 RISC-V 调用约定自己管理栈帧即可。
3.4 sigreturn 为什么必须恢复整个 trapframe
如果只改 epc，handler 确实会被执行，但问题马上就来了：主程序被中断时现场还留在 trapframe 里，等 handler 执行完，它必须回到主程序被打断的位置继续走，而不是回到 handler 开头再跑一遍。这正是sigreturn的职责。
在kernel/sysproc.c里实现：
uint64 sys_sigreturn(void) { struct proc *p = myproc(); *p->trapframe = *p->alarm_saved_trapframe; p->alarm_handler_active = 0; return 0; }这段代码的语义很直白：把进入 handler 前保存的那份完整现场覆盖回当前的p->trapframe，然后清除 active 标志。返回用户态后，CPU 从恢复后的 epc 继续执行，也就是主程序原来被时钟中断打断的那条指令之后，仿佛中间那段 handler 从未发生过。
这里的关键是"整个结构体覆盖，而不是只恢复几个寄存器"。因为中断可能在用户进程执行的任意一条指令处发生，所有寄存器都可能是活跃的。如果你只恢复 epc 和 sp，a0 到 a7 里保存的中间计算结果就全丢了，主程序后续运算一定出错。这个设计思路和真实操作系统里保存/恢复上下文的做法是一致的。
3.5 重入问题的完整解法
现在解释 test1 和 test2 重点考察的重入保护。
我的做法是在触发分支里先检查alarm_handler_active：为 0 才保存副本、设置 epc；为 1 说明当前正处在 handler 内部，即使计数又满了一个 interval，也不会再次劫持。同时，无论是否重入，我都会把alarm_ticks清零。
这里为什么要清零？如果不清零，handler 执行期间alarm_ticks会持续累加，等 handler 通过 sigreturn 结束后，只要计数还有余量，很可能立刻又满足>= interval的条件，导致主程序刚恢复一下就又被劫持，看起来就像闹钟在"连发"。清零之后，闹钟的节奏被重置，handler 结束后要重新等待完整的一个 interval，语义更接近真实信号。
有个容易被忽略的微妙点：handler 内部如果调用了write这类系统调用，会再次陷入内核、更新 trapframe，但并不会覆盖alarm_saved_trapframe，因为这个副本只有在第一次触发 handler 时才写入。之后无论发生多少次普通系统调用或时钟中断，它的内容都保持不变，直到 handler 调用 sigreturn 把它取回。这正是 test2 能通过的根本原因。
实验报告里，我会建议把"为什么不需要加锁"也写一笔：xv6 中同一个进程同一时刻只会被一个 CPU 调度执行，usertrap 处理时钟中断时，另一个 CPU 不会同时运行这个进程并修改它的 proc 字段，因此这里的读写天然是串行化的。这不是侥幸，而是 xv6 进程模型保证的性质。
4. 调试手记：闹钟实验差点让我崩溃的三个瞬间
4.1 trapframe 被覆盖的诡异现象
我第一次实现时图省事，把 handler 地址直接写进了p->trapframe->epc，保存现场用了一个指针变量指向p->trapframe。跑 test0 的结果是：主程序刚开始执行，handler 莫名其妙被调用了很多次，有一次还让 qemu 直接 panic。用 gdb 打断点跟踪后发现，alarm_saved_trapframe的内容在不断增加，每次新中断都会往当前 trapframe 里写，旧现场早就被覆盖得不成样子。等到 handler 调用 sigreturn 时，恢复出来的是一个"已经被第二次甚至第三次中断改写过的现场"，程序自然就跑飞了。
这个坑的教训很简单：凡是用于"恢复原状"的数据，必须放在不会被常规流程自动改写的地方。独立的一份 trapframe 副本，正是为了对抗这一点。
4.2 重入导致的栈越深、越跑越乱
解决了第一部分之后，test1 又给了我当头一棒：handler 里循环等待时，闹钟计数还在走，次数一满，内核又往同一个alarm_saved_trapframe里保存了新的现场，并再次把 epc 设为 handler。于是 handler 还没退出，又从头开始跑，一层套一层，用户栈越来越深，最后 qemu 报出用户栈溢出或者非法指令。
加上alarm_handler_active标志后，情况立刻好了。有个细节是：active 标志必须在 sigreturn 里清 0，而不能在 handler 调用任何系统调用时清。如果你在 sys_sigalarm 里顺手清 0，那么在 handler 内部重新设置闹钟时，会误以为自己不在 handler 中，下一次时钟中断就能重入，test2 就会失败。这也是我把 active 的清除动作专门放在 sigreturn 里的原因。
4.3 用 gdb 看清 usertrap 的每条分支
调试这个实验时，我最常用的操作是在usertrap入口打断点，然后每次触发时检查几个关键值：which_dev、p->alarm_ticks、p->trapframe->epc和p->alarm_handler_active。命令大致是：
(gdb) b usertrap (gdb) c (gdb) p which_dev (gdb) p *p->trapframe (gdb) p p->alarm_ticks (gdb) p p->alarm_handler_active观察which_dev是不是 2，可以确认当前是否是时钟中断；观察alarm_ticks是否在预期位置归零，可以确认计数逻辑没走错分支；观察 epc 是否在触发后被改成了 handler 地址，则可以确认劫持是否生效。配合si单步进入 trampoline 的userret，能看到 sret 之后 CPU 确实跳到了 handler 的第一条指令，这对理解整个 trap 机制帮助巨大。
5. 从 lab4 延伸出去：trap 机制还能干点什么
5.1 通往真实系统信号机制的门票
alarm 实验实现的这套"定时回调 + 现场恢复 + 防重入"，本质就是 Unix 信号（signal）的极简版。真实操作系统的SIGALRM、SIGINT处理流程，会多考虑用户态与内核态栈切换、信号屏蔽字、可重入函数等问题，但底层的"用户态 handler + sigreturn"思路是完全一致的。做完 lab4 再去看真实系统的 signal 实现，很多名词就不再抽象了。
5.2 调试器、快照和性能分析背后的 trap
另一个非常自然的延伸是调试器。gdb 这种工具在用户程序里下断点，依赖软件断点指令触发 trap，内核把控制权交给调试器；单步执行也一样，靠的是 CPU 的单步异常。从这个角度看，lab4 不光是一次课程作业，它把"一切执行流的转移都可以用 trap 机制接管"这个底层事实摆到了你面前。
5.3 如果再做一遍，实验报告我会怎么写
每次写完 lab4 实验报告，我都会发现同一类问题：太多人把代码完整贴上去，然后配一句"运行成功"。这种报告对自己没有沉淀，对读者也没有价值。更好的写法是：
- 实验目的用一句话概括你对 trap 机制的理解，而不是抄题目；
- 代码只贴关键片段，重点是解释每个字段、每个分支"为什么是它"；
- 把调试过程中遇到的两三个反直觉瞬间写下来，这是报告最有含金量的地方；
- 最后贴运行输出，并逐行解释这些输出证明了机制的哪一部分行为。
比如 backtrace 的输出，我会说明哪一行对应sys_sleep，哪一行对应syscall，哪一行是usertrap；alarm 的输出，我会说明为什么 test0 显示 handler 被调用了预期次数，为什么 test1 没有出现重入，为什么 test2 在 handler 内部调用系统调用之后主程序还能正确恢复。这样写出来的报告，哪怕代码不是最优解，也一定能让人看出你是真正做过的。
如果让我重新做一遍，我会把 backtrace 从sys_sleep里挪出来，封装成内核的一个通用调试手段，在 panic 时自动打印调用链。这个改动对实验评分没什么帮助，但对一个操作系统的可观测性来说，价值是实打实的——毕竟真实内核的 panic 信息里，栈回溯是工程师第一眼要找的东西。
