MIT 6.S081 Lab4 Traps 深度解析：从陷阱指令到用户态中断劫持

很多人在学操作系统的时候，对“陷阱指令”的理解始终停留在课本那张图上：用户态和内核态之间有一条鸿沟，ecall是渡桥，sret是返程。但概念归概念，真要自己动手写一段处理陷阱的代码，往往立刻卡壳。MIT-OS2022的lab4 Traps，就是专门把这层窗户纸捅破的实验。它不涉及复杂的数据结构，也不要求你精通调度算法，但它逼着你回答一个核心问题：当一个用户程序因为系统调用、设备中断或异常而“掉进”内核时，CPU和操作系统之间到底是怎么完成交接的。

整个lab由三个子任务构成：阅读RISC-V汇编理解调用约定、实现backtrace栈回溯、实现alarm定时器回调。表面上看三件事互不相干，但做完你会发现，它们其实是从不同角度拆解同一个机制——trap。这篇内容主要适合正在做或准备做MIT 6.S081 lab4的同学，也适合那些想通过完整实验把陷阱指令、系统调用、中断处理彻底搞明白的读者。下面直接进入正题。

1. Lab4到底在讲什么：从“陷阱”这个名词说起

trap这个单词在操作系统里有三层含义：系统调用、异常、设备中断。系统调用是用户程序主动发起的（ecall指令），异常是被动出错（非法指令、缺页、除零），设备中断是外部硬件打断（时钟、键盘、磁盘）。不管哪一种，CPU都必须完成一次“用户态到内核态”的切换，处理完再切回去。

lab4的三个子任务，正好对应这三层含义的落地场景：

很多人以为lab4的重点是写代码，其实它真正的难点是“读懂控制流的迁移”。特别是alarm这一部分，表面上只是加两个系统调用，实际上它让用户程序有机会“在任意位置被中断，执行另一个函数，再恢复回原位置继续跑”。这个过程要是没想明白，写出来的代码即使通过了测试，也只是碰巧对了。

1.1 陷阱、异常、中断的优先级与处理差异

RISC-V把trap统一处理，但区分source。在xv6中，usertrap()函数里通过scause寄存器的值来判断这是哪一类事件：scause == 8表示系统调用，小于32表示异常，大于等于32表示中断。设备中断里，定时器中断对应的which_dev返回2。

这里有一个初学者很容易漏掉的点：系统调用触发trap时，用户PC已经指向了ecall的下一条指令。也就是说，处理完系统调用后返回用户态，不需要再手动把epc加4。但如果是外部中断，用户PC还在被中断的那条指令上，恢复后要重新执行这条指令。这个区别在lab4的alarm部分会直接影响你的判断：定时器中断回来后，用户程序必须能从“原来的位置”继续跑，而不是从handler的地址开始。

1.2 三个子任务的能力渐进关系

热身任务要求你回答一系列关于call.asm的问题，比如“哪个寄存器保存了printf的第一个参数？”“f()被内联了吗？”这些问题不写代码，但非常重要。如果你回答不了，说明你还没建立“函数调用到底发生了什么”的直觉，backtrace就会变成凭空瞎调。

backtrace让你在内核里沿着栈帧找调用链，本质上是把热身阶段理解的栈帧布局用代码表达出来。实现起来只有十几行，但涉及指针强转、地址边界判断，对C语言的功底有一定要求。

alarm是最高潮的部分，它让你站在内核的角度“劫持”用户程序的执行流。你需要理解trapframe里每个字段的作用，理解为什么修改trapframe->epc就能改变用户程序的下一条指令，理解为什么handler执行完之后必须有一个“恢复现场”的系统调用。做完alarm，你对操作系统“上下文切换”这个概念的理解会有一个质的飞跃。

2. 热身：call.asm与RISC-V调用约定

lab4的第一个任务不写代码，阅读call.asm并回答问题。这段实验材料很有代表性，它把函数调用的底层细节全部暴露了出来。我建议你先自己编译一遍，再看我下面的分析。

2.1 RISC-V的函数调用约定速览

RISC-V里，函数调用的约定比x86要简洁一些：

• a0~a7用于传参数，多余的参数通过栈传递
• ra寄存器保存返回地址
• sp指向栈顶，栈向低地址增长
• s0也就是fp（帧指针），指向当前栈帧的底部

关键点在于：返回地址保存在寄存器里，而不是栈上。但函数调用会发生嵌套，内层的ra会覆盖外层的ra，所以非叶子函数必须在入口处把ra保存到自己的栈帧里，在返回前再恢复。

一个典型的RISC-V函数序言（prologue）长这样：

code复制addi  sp, sp, -16   # 分配16字节栈空间
sd    ra, 8(sp)     # 保存返回地址
sd    s0, 0(sp)     # 保存帧指针
addi  s0, sp, 16    # 设置新的帧指针

这就是栈帧的最基本骨架。后面backtrace的实现，就是逆着这个骨架往回走。

2.2 call.c编译后发生了什么

c复制int g(int x) {
  return x+3;
}

int f(int x) {
  return g(x);
}

void main(void) {
  printf("%d %d\n", f(8)+1, 13);
  exit(0);
}

这段代码编译到call.asm后，你会看到一些有意思的细节。

第一，f()和g()都被编译器内联了。main里根本没有调用f或g的汇编指令，两个函数的计算结果在编译期就确定了：f(8)+1 == 12。所以printf的第二个参数直接就是常数12。

第二，printf的参数传递顺序：格式化字符串地址放到a0，12放到a1，13放到a2。如果你去看call.asm的main部分，会看到：

code复制li      a2, 13
li      a1, 12

先加载后面的参数，再加载前面的。这是RISC-V调用约定的常见编译结果——编译器会从后往前计算参数表达式，但不代表参数的从右到左压栈（RISC-V不是栈传参）。这个顺序细节在x86的C调用约定里也很常见，但RISC-V没有“压栈”这个动作，参数都是放寄存器。

第三，printf的调用方式：

code复制auipc   ra, 0x0
jalr    1540(ra)

auipc加jalr组合，是RISC-V里调用远距离函数的通用方式。auipc先把PC的高20位加上立即数放到ra，jalr再把低12位偏移加进去，得到目标地址并跳转。这里顺便完成了“把返回地址写入ra”的任务。注意printf的地址在编译链接时就确定了，因为这是内核编译环境，没有动态链接。

2.3 热身问题的几个关键答案

热身问题里有几个坑，我当年做的时候错了两道。整理如下：

• 哪些寄存器保存了函数的参数？ a0~a7。超过8个参数才用栈。
• main调用printf时，printf的参数放在哪个寄存器？ 格式化串地址在a0，12在a1，13在a2。
• main的汇编里，f是怎么被调用的？ 没有被调用，内联了。编译器在编译期就算出了f(8)+1的结果。
• printf的地址是多少？ 在编译产物里是相对地址，通过auipc+jalr跳转，实际地址由链接器决定。
• jalr指令执行后，ra寄存器的值是什么？ printf函数返回后要执行的指令地址，也就是jalr的下一条指令地址。

最后一个问题很关键，因为它涉及ra的保存时机。main调用printf之前，先把ra保存到了栈上（sd ra, 8(sp)），这是因为main自己也是被调用的，它需要知道printf返回后回到哪里。这个“保存现场再调用”的模式，是整个函数调用机制的核心。

3. Backtrace：从栈帧到函数调用链

第二个任务是实现backtrace()，在内核出错时打印当前函数调用链。这个功能在真实内核里太常用了，panic的时候如果能打出调用栈，排错效率能翻好几倍。xv6的panic()里调用了backtrace()，所以我建议你完成之后顺手把backtrace()加到panic里，后面debug会非常舒服。

3.1 原理：顺着帧指针链往回走

前面讲了栈帧的布局，现在派上用场了。在RISC-V的栈帧中：

• 当前栈帧的fp + 0位置，保存的是上一层的fp
• 当前栈帧的fp + 8位置，保存的是返回地址ra

所以只要你拿到当前函数的fp，就能通过内存寻址找到上一层的fp和返回地址，然后让fp = *(fp)，重复这个过程，直到栈顶。

要注意的是，RISC-V里的寄存器只有fp寄存器（也就是s0），CPU不会自动帮你维护“当前栈帧底在哪”。你需要显式地读出s0的值。xv6的riscv.h里其实已经有现成的inline函数：

c复制static inline uint64
r_fp()
{
  uint64 x;
  asm volatile("mv %0, s0" : "=r" (x) );
  return x;
}

我在实现时就用了这个，没有自己写内联汇编。如果你发现riscv.h里没有r_fp，自己加一个就行。

3.2 核心实现：十几行代码搞定

c复制void
backtrace(void)
{
  uint64 fp = r_fp();
  uint64 top = PGROUNDUP(fp);

  printf("backtrace:\n");
  while (fp < top) {
    uint64 ra = *(uint64 *)(fp + 8);
    printf("%p\n", ra);
    fp = *(uint64 *)fp;
    if (fp == 0)
      break;
  }
}

逻辑很简单：读当前帧指针，打印当前帧中保存的返回地址，然后把帧指针更新为上一帧的帧指针。循环终止条件是fp超过了当前栈页的上边界，或者fp变成了0。

这里有一个关键的设计取舍：为什么用PGROUNDUP(fp)作为边界，而不是用一个固定次数？ 因为不同调用路径的栈帧深度不同，固定次数会漏掉或越界。而只要帧指针落在同一个页内，就说明还在当前栈中。如果你用fp >= KERNBASE这种内核栈边界判断，原理上也可以，但和我上面这种写法比起来，页边界判断更精确，也不容易受其他环境因素影响。

3.3 把backtrace挂到panic上

在kernel/printf.c中包含了riscv.h之后，要把backtrace()的声明加到kernel/defs.h：

c复制void            backtrace(void);

然后在panic()函数里调用：

c复制void
panic(char *s)
{
  pr.locking = 0;
  printf("panic: ");
  printf(s);
  printf("\n");
  backtrace();
  panicked = 1;
  for(;;)
    ;
}

这一步不算lab要求，但实测下来非常值得。遇到任何一个内核panic，都能直接看到调用栈，定位到出错函数，比一行行猜快多了。

3.4 边界条件的坑

backtrace看起来简单，但有几个边界条件容易翻车。

第一个是空指针。帧指针链总会有尽头，如果某帧的fp内容被破坏成0或非法地址，循环条件fp < top就失效了，可能会读到一个非常离谱的地址然后crash。所以我在循环里加了一个if (fp == 0) break;的保险。

第二个是打印锁。printf本身有自旋锁保护。如果在panic已经持有pr.locking=0的情况下调用backtrace，printf不会再拿锁，这个没问题。但如果你在别的地方（比如某个持锁路径）调用backtrace，两个打印流交错，输出会乱掉。一般不会遇到，因为backtrace基本只在panic里用。

第三个是对齐问题。栈帧的地址通常是16字节对齐的，但如果你在某些特殊上下文（比如刚进入陷阱处理）调用backtrace，fp可能指向的是一个合法的地址但没有按帧结构排列。我的建议是：backtrace的调用位置越“深”越安全，最好只在内核已知的普通函数调用路径上调用，不要在汇编陷阱入口里直接调。

4. sys_sigalarm与sys_sigreturn：劫持用户程序的执行流

alarm是lab4的重头戏，也是整个lab里最能体现trap机制精髓的部分。需求本身很好理解：用户程序调用sys_sigalarm(interval, handler)，要求内核每隔interval个时钟周期，就调用一次用户提供的handler函数。handler执行完后，用户程序要继续像什么都没发生一样运行。

4.1 先拆解需求：三个测试各考什么

lab给了三个测试：

• test0：周期性调用handler，handler只做简单计数，不涉及“恢复现场”。也就是说，handler执行完之后跳回用户程序，但用户程序本身已经无所谓“现场”了。最简单的实现就能过。
• test1：handler执行完之后，用户程序必须从被中断前的那条指令继续执行，并且循环变量计数正常。
• test2：在test1基础上，检查handler执行前后所有寄存器的值是否一致，本质上是在验证现场保存和恢复的完整性。

test0和test1/2的区别在于：test0不需要保存和恢复用户的上下文，因为测试程序的设计就是“被打断也无所谓”。从test1开始，你必须让用户程序在handler执行完以后，完美恢复到中断前的状态。

这就是为什么lab4的难度集中在test1/2上，而不是test0。

4.2 内核如何“劫持”用户程序的执行流

正常的trap处理流程是：用户程序在用户态执行ecall，CPU跳到内核的uservec，保存用户寄存器到trapframe，然后执行usertrap处理系统调用/中断，最后通过usertrapret恢复trapframe，sret回到用户态。

alarm的巧妙之处在于：当时钟中断发生时，usertrap里可以修改trapframe->epc。epc是用户程序的下一条指令地址，usertrapret会把epc写回CPU的sepc寄存器，sret后CPU就跳到了新的地址。如果我把epc改成handler的地址，那sret返回用户态后，用户程序就会跳到handler去执行。

这就是“劫持”的原理。你不需要在用户态做任何事，只要在内核里改一个字段，就能让用户程序改变运行方向。操作系统对用户程序的控制力，在这里体现得淋漓尽致。

4.3 在proc结构体中扩展字段

要在kernel/proc.h的struct proc里增加几个字段：

c复制  int alarm_interval;            // 定时器间隔，单位为ticks
  uint64 alarm_handler;          // 用户态handler的地址
  int alarm_ticks;               // 距离上次触发已经过去的ticks数
  struct trapframe *alarm_trapframe;  // 保存中断前的完整现场
  int alarm_going_off;           // 标记handler是否正在执行

alarm_trapframe需要分配一个独立的trapframe结构，不能直接复用p->trapframe——因为你在保存现场的时候，p->trapframe还在被内核使用，不能覆盖它。我建议在allocproc里分配，在freeproc里释放，和p->trapframe的生命周期保持一致。

4.4 sys_sigalarm的实现

c复制uint64
sys_sigalarm(void)
{
  int interval;
  uint64 handler;

  argint(0, &interval);
  argaddr(1, &handler);

  struct proc *p = myproc();
  p->alarm_interval = interval;
  p->alarm_handler = handler;
  p->alarm_ticks = 0;
  p->alarm_going_off = 0;
  return 0;
}

这里几乎没有难点，就是接收参数、存到proc里。注意argint和argaddr的区别：interval是整数用argint，handler是地址用argaddr。如果你混用了，读出来的值会错得离谱，而且很难排查。

有个细节：test0里会调用sigalarm(0, handler)来关闭定时器。所以sys_sigalarm里不能直接忽略interval=0的情况，要把alarm_interval设置成0，这样后面在usertrap里判断if (p->alarm_interval > 0)就自然关闭了。

4.5 usertrap里触发回调

这是alarm的核心逻辑。在kernel/trap.c的usertrap中，设备中断分支（which_dev == 2）需要增加以下代码：

c复制  if (which_dev == 2) {
    if (p->alarm_interval > 0) {
      p->alarm_ticks++;
      if (p->alarm_ticks >= p->alarm_interval && !p->alarm_going_off) {
        p->alarm_ticks = 0;
        p->alarm_going_off = 1;

        // 保存当前完整现场
        *p->alarm_trapframe = *p->trapframe;

        // 劫持返回地址，让用户态跳到handler
        p->trapframe->epc = p->alarm_handler;
      }
    }
    yield();
  }

注意顺序：必须先保存现场，再改epc。如果先改epc再复制，那保存下来的现场里epc已经是handler地址了，等sys_sigreturn恢复现场时，用户程序就会回到handler而不是原来的位置，直接死循环。

为什么要有alarm_going_off标志？因为handler执行期间（用户态），定时器中断还在不断发生。如果不加这个标志，第二次中断进来时会再次触发回调，把epc再次改成handler地址，结果就是已经执行到一半的handler被再次调用，形成无限递归。加了标志以后，只要handler还没通过sigreturn返回，就禁止再次触发。

4.6 sys_sigreturn的实现：把现场还回去

c复制uint64
sys_sigreturn(void)
{
  struct proc *p = myproc();

  *p->trapframe = *p->alarm_trapframe;
  p->alarm_going_off = 0;

  return p->trapframe->a0;
}

这短短几行里其实藏着一个非常容易绕晕的点。syscall()函数在调用完sys_sigreturn之后，会把返回值写到p->trapframe->a0，然后返回用户态时，用户程序看到的a0就是这个返回值。由于我们已经把trapframe恢复成了中断前的样子，p->trapframe->a0就是中断前用户程序的a0。这个值被当作sys_sigreturn的返回值，然后再次写回trapframe->a0。最终用户程序看到a0还是原来的值，相当于“什么都没有发生”。

如果你把sys_sigreturn改成“先保存return value，再恢复trapframe”，结果也是一样的，因为最终trapframe->a0都会被正确的值覆盖。但最简洁的写法就是先恢复，再返回恢复后的a0。

4.7 为什么test2能检查出寄存器恢复不完整

test2的机制是：在调用sigalarm之前，先把一些寄存器的值设成特定值，然后handler里不修改这些寄存器，测试程序在handler执行完后检查这些寄存器是否还是原值。

这就意味着：handler的执行一定会修改一堆寄存器（至少ra、sp、t0~t6这些临时寄存器都可能被改）。如果不做现场恢复，用户程序从handler返回后再检查这些寄存器，看到的全是被handler破坏过的值，test2就会挂掉。

所以test2的真正含义是：内核必须做到“handler对用户程序来说是一个透明的函数调用”——执行完以后，除了a0可能和预期不同，其他所有寄存器都必须和调用前一致。而这恰恰是通过sys_sigreturn恢复整个trapframe实现的。

4.8 内存分配与释放的配套修改

别忘了在allocproc里分配alarm_trapframe：

c复制  if ((p->alarm_trapframe = (struct trapframe *)kalloc()) == 0) {
    freeproc(p);
    release(&p->lock);
    return 0;
  }

在freeproc里释放：

c复制  if (p->alarm_trapframe)
    kfree((void*)p->alarm_trapframe);
  p->alarm_trapframe = 0;

这一步容易漏，漏了之后运行时会出“unexpected scause”之类的随机crash，因为内存被意外覆盖了。

5. 把trap机制串起来：从ecall到sret的完整链路

做完alarm之后，一个完整的trap链路就在你手里被拆开又组装了一遍。这里我把它完整串一遍，你会发现lab4的三个任务其实是一条线。

5.1 硬件做了什么，软件做了什么

当用户程序执行ecall时，硬件完成以下动作：切换到S-mode（内核态）、把当前PC保存到sepc、把ecall的cause写入scause、跳转到stvec指向的地址。

注意：硬件只做了这几件事。保存用户寄存器、切换到内核栈、加载内核页表这些活，全都是软件在stvec指向的代码里完成的。xv6把stvec设置为trampoline页中的uservec。这就是为什么trampoline页要同时映射在用户虚拟地址空间的最顶部（MAXVA-PGSIZE）和内核虚拟地址空间的相同位置——因为从用户态跳过来时，页表还没切换，必须让这段代码在用户页表和内核页表里都能被找到。

5.2 trampoline与trapframe的分工

uservec的汇编代码做的第一件事是：交换a0和sscratch。sscratch在用户态时被设置成trapframe的地址，交换后a0指向了trapframe，原来的a0被暂存在sscratch里。然后，uservec把用户的所有寄存器保存到trapframe对应偏移的位置。

trapframe是内核为每个进程分配的物理页，里面存放用户态寄存器的“快照”。之所以不用一个普通结构体数组，是因为汇编代码需要精确知道每个寄存器的保存位置，而struct trapframe的偏移量在编译时是确定的，直接用偏移寻址就可以了。

5.3 usertrap和usertrapret的分工

trapframe保存完寄存器后，uservec会加载内核栈指针、内核页表的satp，然后跳转到usertrap这个C函数。usertrap根据scause判断是系统调用、异常还是中断：

• 系统调用：处理完把trapframe->epc += 4，跳过ecall本身
• 异常：打印信息，可能要杀掉进程
• 设备中断：让出CPU，等待下一次调度

处理完以后，usertrapret做反向操作：把trapframe里的寄存器恢复回CPU，设置stvec为uservec（为下一次trap做准备），然后执行sret。注意：sret会把sepc写回PC，而sepc已经被usertrapret设置成了trapframe->epc。

alarm就是在这个流程里“偷梁换柱”：中断发生时，usertrap发现定时器到期，就把trapframe->epc从“原来的下一条指令”改成了“handler的地址”。这样sret之后，用户程序跑的就不是原来的代码，而是handler了。等到handler里调用sigreturn，又把trapframe恢复成中断前快照的样子。两条trap路径一正一反，就实现了用户态定时回调。

5.4 系统调用的本质

在xv6里，系统调用不是通过什么神秘机制实现的。用户程序把系统调用号放进a7寄存器，把参数放进a0~a5，执行ecall。内核的syscall()函数从trapframe里读出a7，查syscalls表，调用对应的处理函数。处理完的返回值再写回trapframe->a0，用户程序ecall之后从a0里拿到的就是返回值。

lab4里的sys_sigreturn非常特殊：它不光要返回一个值，还要把整个寄存器环境恢复回去。从这点上说，它已经跨进了“上下文切换”的领域，只是切换的对象不是进程，而是同进程内两段不同的用户代码。如果你能把这些想明白，后面的进程调度实验会轻松很多。

6. 实测遇到的问题与调试方法

最后一个part分享我在实际做lab4时遇到的一些问题和对应的调试手段。每一条都是踩过的坑，不是从文档里抄的。

6.1 backtrace打印出了奇怪的地址

第一次实现backtrace时，我打印出来的地址不是预期的内核函数地址，而是一些看起来完全随机的数值。排查过程如下：

先用gdb在backtrace函数入口断住，看s0的值是否正常。然后手工检查栈内存：x/20gx $s0，确认fp+0位置是否是上一帧的fp，fp+8是否是返回地址。

最后发现问题：我在printf.c里写backtrace，但printf.c没包含riscv.h，导致r_fp()没有被正确内联，读出来的不是s0而是某个临时寄存器的值。加上#include "riscv.h"之后就好了。

6.2 alarm的test0过了，test1/test2死循环

这个现象几乎可以断定是epc没有正确恢复。test0的测试程序本身不检查“现场是否完整”，所以即使epc改错了，程序也可能碰巧跑完。但test1会检测循环计数，test2会检测寄存器，任何一个状态不对都会挂。

我在test1卡了很久，最后查到原因：在sys_sigreturn里恢复trapframe之前，忘了把alarm_going_off清零。结果第二次定时器中断进来时认为handler还在执行，不再触发回调。逻辑上看起来“安全”，但实际上用户程序永远停在handler返回后的某条指令，或者循环计数完全不对。

修复很简单：先恢复trapframe，再清零alarm_going_off。注意两个操作的顺序。

6.3 推荐调试工具与方法

调试lab4，我用的几个手段挺有效：

第一，make qemu-gdb配合gdb断点。在kernel/trap.c的usertrap里打断点，查看p->trapframe->epc在中断前后分别是什么值，能非常直观地看到劫持效果。

第二，在内核路径上加临时printf。比如在usertrap的定时器分支里打印ticks和epc。虽然粗暴，但在理解不清控制流的时候，一次打印比十次推理都管用。

第三，用addr2line把内核地址转成源码位置。backtrace打印出的地址，可以反查：

bash复制addr2line -e kernel/kernel 0x80001234

这个命令会把内核虚拟地址对应到源码文件和行号。在调试panic的时候，一行命令就能定位崩溃位置。

6.4 自测思路：别只盯着判分脚本

xv6的lab通常自带测试脚本，但测试脚本只告诉你“过没过”，不告诉你“为什么没过”。我建议拿到测试程序之后，先读一遍测试代码，搞明白它到底在测什么。

比如alarmtest.c的test0，它只是每隔一段时间调用一个简单的handler，handler里只做计数，没有系统调用。而test1的handler里调用了write——这就让“handler执行期间发生时钟中断”的概率大大增加了，如果你的alarm_going_off或trapframe恢复逻辑有问题，崩溃得会比test0快得多。提前理解这些差异，能帮你快速缩小排查范围。

还有一个自测的小技巧：在实现sys_sigreturn时临时写一个“不恢复现场”的版本，跑一遍test1，观察崩溃现象。这个方法可以帮你确认“到底是哪个寄存器没恢复对”，比盲改代码有效得多。

6.5 最后一个容易忽略的细节

在usertrap的定时器分支里，我一开始把yield()放在了判断alarm条件的外面，后来发现这样也行，但每次时钟中断都让出CPU，会导致alarm的周期准确度下降。把这个细节想清楚可以为lab里的其他实验打底：操作系统里“中断处理完了不一定立即返回用户态，可能先调度到别的进程”这个基本逻辑，在这个lab里提前感受一次，后面做进程调度会容易理解得多。