简介南京大学计算机系统课程ICS2017编程作业项目提供了覆盖模拟器、抽象层、操作系统到应用程序的完整教学实验框架其中NEMU负责微处理器模拟NexusAM承担硬件抽象接口NanosLite实现轻量内核NavyApps承载示例应用适合希望夯实计算机系统底层能力的学生或开发者用于课程配套实验与自学。压缩包共877个文件以C语言工程为主体538个c、183个h另含22个cpp、makefile与mkf构建脚本、Markdown笔记、少量汇编源文件、Python辅助工具以及字体和NES游戏镜像等整体仅18.6MB便于下载后快速查阅与编译。目前已有97人学习浏览。使用者可以沿着NEMU逐步实现指令解析与执行再借助NexusAM完成中断和输入输出进而在NanosLite上加载NavyApps中的程序验证系统调用与进程调度形成从硬件到软件的完整闭环。配套的说明文件和可执行脚本也能帮助定位实验难点尤其适合作为计算机系统方向的项目式训练素材。1. 一套能“长出操作系统”的计算机系统教学实验框架它到底在教什么这个标题乍看很长拆开其实只在讲一件事某高校计算机系统课程的教学实验框架把“一台能跑程序的计算机”拆成教学模拟器、硬件抽象层、微型操作系统和用户程序四层压缩包里的就是这四层从零到能跑系统调用的整套脚手架。很多人学系统课程第一反应是去翻开源操作系统内核的源码结果面对百万行代码直接劝退这套框架的思路正好反过来——不是“读操作系统”而是“造操作系统”。你要先在模拟器里让第一条指令跑起来再通过一层薄薄的硬件抽象层把一个只有几条核心机制的小型操作系统“种”出来最后让用户程序在它上面正常打印、退出、调度。这套体系适合三类人被传统“背诵式”系统课劝退的本科生想给学生布置整学期综合实验的高校教师以及所有想亲眼看清指令执行、ELF 装载、上下文切换、系统调用这几件事实际长什么样的从业者。它的价值不在模拟器本身多强大而在四层之间那条清晰的“接缝”——每层都可以被单独修改、单独调试、单独验证。只要沿着这条缝往下走一个只写过 C 语言的人也能在几周内亲手拉起一套完整的小系统。2. 框架三层结构与构建体系模拟器、抽象层、操作系统是怎么咬合的2.1 为什么需要“中间那层抽象”先讲一个真实痛点如果你直接在一个裸模拟器上写操作系统那这个系统天生就和某一种指令集绑死了。换一个 CPU 架构中断控制器要改时钟要改串口输出要改甚至连进程切换时该保存哪些寄存器都要重来。教学实验最忌讳的就是这种“一换平台全盘推翻”的挫败感因为学生根本没精力在两周内同时学会 RISC-V 的调用约定和 x86 的中断门描述符。所以这类框架在模拟器和操作系统之间普遍会插入一个“硬件抽象层”也就是标题里那个抽象层概念。它的定位不是模拟器的一部分也不是操作系统的一部分而是两者之间的一份契约模拟器负责把这些设备的真实行为通过一组固定接口暴露出来操作系统只对着这组接口编程完全不过问底层的寄存器细节。这样做的直接收益是将来想换一种指令集抽象层的接口可以原封不动只要把接口背后的实现换掉上面的操作系统一行都不用改。抽象层该提供哪些能力是这套框架设计里最有讲究的地方。太少了撑不起操作系统太多了又会让实验退化成“照着手册调驱动”。一个合适的边界大致是处理器上下文初始化、物理内存的读写、一个串口或帧缓冲用于输出、一个可编程定时器用来触发时钟中断、外加开关中断和注册中断处理函数的能力。我见过有些框架把磁盘控制器也抽象进去但对教学实验来说反而喧宾夺主学生多半会卡在调试磁盘镜像上而不是理解操作系统。// 抽象层对外接口示意操作系统代码只需要包含这个头文件 #ifndef HAL_H #define HAL_H #include stddef.h #include stdint.h #define HAL_DEV_UART 0 // 串口 #define HAL_DEV_TIMER 1 // 定时器 #define HAL_DEV_FB 2 // 帧缓冲 // 从设备读取 len 字节到 buf返回实际读取的长度 int hal_dev_read(int dev, void *buf, size_t len); // 向设备写入 len 字节返回实际写入的长度 int hal_dev_write(int dev, const void *buf, size_t len); // 开关中断enable1 允许触发返回之前的中断状态 int hal_irq_set_enable(int enable); // 注册一个中断处理函数irq 为中断号 void hal_irq_register(int irq, void (*handler)(void)); // 延时 n 毫秒供轮询类驱动使用 void hal_delay_ms(uint32_t n); #endif这段接口设计里有一个值得注意的细节所有读写都采用“设备号 缓冲区指针 长度”的签名而不是直接给每个设备独立的 read/write 函数。好处是新增设备时不需要改操作系统的调用点只要在 hal 内部加一个 case坏处是参数里少了一个“偏移量”所以这套接口天然适合串口这类顺序读写设备。如果你想把抽象层扩展成支持可寻址的存储型设备建议在签名里再加一个 offset 参数否则后面做虚拟磁盘时接口要重新设计。2.2 工程目录与 Makefile先让框架自带的镜像跑起来拿到压缩包以后第一步不是急着看代码而是把整棵目录树理清楚。典型布局是顶层分出模拟器、抽象层、操作系统、应用程序和构建工具这几个目录外加一个 Makefile 把全部模块串起来。其中模拟器基础设施是纯软件直接在主机上用 GCC 编译即可而从抽象层往下代码最终要跑在模拟器里所以必须用交叉编译器把操作系统的二进制编出来。我拿到这种工程的第一动作永远是先跑一次自带的预编译镜像确认环境没问题再开始动代码。盲目上来就写很容易把“自己代码的 bug”和“工具链问题”混在一起后面查错查到头秃。下面这组命令就是我从零开始跑通整套框架的固定套路# 1. 解压并进入顶层目录 unzip ics-course-framework.zip cd ics-course-framework # 2. 先做一次全量构建生成模拟器可执行文件和操作系统镜像 make clean make -j$(nproc) # 3. 启动模拟器进入交互调试界面 make run这三条命令背后其实藏着一个容易被忽略的规则模拟器本体是主机程序依赖主机 GCC操作系统镜像则是给模拟器“喂”的固件依赖交叉编译工具链。如果你的 make 报错信息指向找不到某个编译器前缀比如riscv64-unknown-elf-gcc说明交叉工具链没有装全这时候返工去调 Makefile 是浪费时间直接补装工具链才是正解。构建成功以后make run会弹出一个带命令行的模拟器界面输入c让它连续运行理论上可以看到操作系统启动后打印出欢迎信息。如果你在make run之后屏幕上什么都没有多半不是模拟器坏了而是镜像的入口地址有问题。此时退回调试界面用si单步执行几轮看程序计数器是不是一开始就跳到了非代码区域。确认环境以后我通常会把模拟器自带的调试指令全部敲一遍info reg看寄存器、x/10 0x80000000看内存、si 10走十步。这个过程相当于给整套系统做一次“体检”也为后面自己加指令和改操作系统打底。2.3 从二进制镜像到“上电启动”一条构建链理解了目录和构建命令接下来值得花十分钟把“从 C 源码到模拟器里的可执行程序”这条链路走清楚。你不必现在就会写链接脚本但你必须知道链接脚本在这套框架里扮演的角色否则后面会遇到“代码明明编译通过了跑起来却像玄学一样随机崩溃”的尴尬场面。整条构建链大致是源码和汇编文件经交叉编译器变成 ELF 目标文件然后用链接脚本把它们按指定地址摆放得到最终的 ELF接下来模拟器并不直接吃 ELF而是用工具把 ELF 转成裸镜像所谓“裸镜像”就是把 ELF 中需要装载到内存的部分原样抠出来拼成一段连续的内存初始内容最后模拟器启动时把这整段内容当作物理内存的初始状态并把程序计数器设置成链接脚本里规定的入口点。这里最关键的一个数字就是“链接地址”。模拟器约定的内存起始地址是 0x80000000那链接脚本就必须把代码段的加载地址也设成 0x80000000。只要这两边不一致第一条跳转指令就会把程序计数器带到空白内存区域结果就是“屏幕什么都不显示单步也看不出规律”。/* 链接脚本片段规定代码段、数据段、BSS 段的装载地址 */ OUTPUT_ARCH(riscv) ENTRY(entry) MEMORY { RAM (RWX) : ORIGIN 0x80000000, LENGTH 128M } SECTIONS { . 0x80000000; .text : { *(.text.entry) *(.text*) } RAM .rodata : { *(.rodata*) } RAM .data : { *(.data*) } RAM .bss : { *(.bss*) } RAM _end .; }链接脚本里值得注意的参数有两个ORIGIN是内存起始地址必须与模拟器的物理内存布局完全一致_end是一个导出符号启动代码会用它来计算 BSS 段范围进而完成清零。我把这个脚本单独拎出来讲是因为它就是“编译通过但运行失败”的最大温床。检验方法很简单在模拟器里打印第一条指令的地址如果和ENTRY指定的入口不一致那问题几乎一定出在这里。3. 从模拟器到抽象层跑通最小可执行程序3.1 最小执行循环让模拟器打印第一条指令整个框架的地基是模拟器它是一个逐条取指、译码、执行指令的循环。理解这个循环你就理解了“CPU 是怎么跑起来的”这个问题的一半。模拟器启动以后把程序计数器设置成 0x80000000然后进入一个死循环从内存读 4 字节当成指令解析出操作码和操作数执行对应的操作再把程序计数器加 4然后重复。分支和跳转指令则直接改写程序计数器从而打断这个线性递增。在它的初始状态下模拟器跑起来是个彻底的黑匣子你不给它加输出你根本不知道它执行到了哪条指令。所以跑通模拟器的第一步就是在这个循环里加一条“打印流水”。// 模拟器核心执行循环位于 simulate.c示意版本 static void cpu_exec(uint64_t n) { for (uint64_t i 0; i n; i) { vaddr_t pc cpu.pc; uint32_t inst vaddr_read(pc, 4); // 从内存读一条指令 exec_inst(inst); // 译码并执行这条指令 cpu.pc 4; // 默认顺序执行 if (trace_enable) { // 打印当前指令地址、机器码和寄存器 0 的值 printf(pc0x%08x inst0x%08x a0%d\n, pc, inst, cpu.gpr[10]); } if (cpu.halt) break; // 遇到停机指令则退出 } }这段代码里有三个参数值得自己调一调。第一个是n它决定本次连续执行多少条指令调试早期建议设置成 1配合单步命令用第二个是trace_enable我的习惯是把它做成命令行参数而不是编译期常量这样不用重新编译就能切换详细输出和安静模式第三个是打印哪几个寄存器前期只打a0和pc就够了等开始调函数调用时再补上ra和sp否则一行输出几十个寄存器反而看不出规律。3.2 抽象层初始化把“裸机”包成一个干净入口模拟器能执行指令以后下一步是把控制权交给抽象层的启动代码。这里面最容易被忽略、也最容易出问题的是“从模拟器跳进操作系统 C 代码之前”那段汇编。模拟器上电时寄存器全部是随机值栈指针尤其不可信如果在没有建立栈的情况下直接调用 C 函数第一个函数调用的返回地址会被压到一个非法地址然后整个系统瞬间崩溃。所以抽象层的入口代码必须在跳进os_main之前把栈、BSS 段和入口条件全部准备好。# 抽象层启动入口模拟器把 pc 设到 _start 之后执行到这里 la sp, _stack_top # 建立栈指针_stack_top 来自链接脚本 la t0, _bss_start # BSS 段起始地址 la t1, _bss_end # BSS 段结束地址 bss_clear_loop: bge t0, t1, bss_clear_done sw zero, 0(t0) # 把 BSS 段逐字清零 addi t0, t0, 4 j bss_clear_loop bss_clear_done: call os_main # 跳进操作系统的 C 入口这段代码在几乎所有教学框架里长得都差不多因为它解决的是一组确定的硬件初始化需求。_stack_top这个符号必须由链接脚本提供通常放在内存最高地址因为栈是向下增长的_bss_start和_bss_end同样来自链接脚本它们圈定的范围必须包含所有未初始化全局变量。BSS 清零这步我见过很多人偷懒跳过后果是某个全局标志位初始值随机程序行为一会儿对一会儿错而且极难复现。这种问题调试起来非常费神所以我的建议是这段汇编一个字节都别省写完就再也不要动它。3.3 加一条自定义指令验证模拟器与抽象层的配合模拟器和抽象层各自能跑通只说明环境没问题还没验证“上下层的契约真的成立”。最干净的验证方式是给模拟器加一条全新的自定义指令然后在抽象层之上的汇编代码里调用它。这样一来你同时动了硬件层、硬件抽象层和测试程序三层只要这条指令能正确执行并回传结果就说明整条链路是通的。以给模拟器加一条“统计一个 32 位整数中 1 的个数”的指令为例。我的做法分三步先在模拟器的译码表里为某个预留操作码加上对应的执行函数然后在抽象层的头文件里用内嵌汇编封装一个函数最后写一个只有几行的测试程序调用这个函数并把结果打印出来。验证标准很明确用主机 GCC 算一遍同样的数两者结果必须一致。// 模拟器中新增指令的执行逻辑示意 static void exec_cnt1(vaddr_t pc, uint32_t inst) { int rd (inst 7) 0x1f; // 目标寄存器编号 int rs1 (inst 15) 0x1f; // 源寄存器编号 uint32_t val cpu.gpr[rs1]; int count 0; for (int i 0; i 32; i) { count (val i) 1; } cpu.gpr[rd] count; }这段逻辑本身不复杂但把它加进模拟器后有两种典型的“验收姿势”。一种是直接看cpu.gpr[rd]在单步执行后的值适合验证指令译码正确另一种是让抽象层封装的函数用 C 语言调用并打印结果适合验证整条工具链和调用约定没问题。我推荐两个都做因为前者能精确定位模拟器的问题后者能暴露抽象层封装时的寄存器误用——常见错误是在内嵌汇编里改坏了某个调用者保存寄存器结果测试函数返回后父函数的局部变量莫名其妙变了。4. 在抽象层上搭建微型操作系统并加载用户程序4.1 系统调用与中断入口操作系统第一次“活”过来有了能执行程序的模拟器和干净的抽象层入口下一步就是让操作系统“活”过来。所谓“活过来”第一个标志是它能够响应中断和异常。操作系统运行在一种特权模式下用户程序运行在另一种模式下两者之间不能直接跳转只能通过一项称为“陷阱”的机制完成切换用户程序发起系统调用或者硬件触发时钟中断处理器停下当前程序跳转到操作系统注册好的入口地址。这个入口是所有操作系统的命门整套上下文保存和恢复逻辑都挤在这几十条汇编指令里。我见过很多初学者在这里翻车保存寄存器时少压了几个返回时就出现“寄存器里凭空多出奇怪值”的灵异现象。正确的顺序是先把所有通用寄存器压栈再切换到内核栈然后调用 C 语言中断处理函数返回时按完全相反的顺序弹栈并把最后一条指令设置成“从陷阱返回”。# 陷阱入口示意进入时已经由硬件切换到内核态 trap_entry: # 先把所有通用寄存器压到当前栈上 addi sp, sp, -128 sd x1, 112(sp) sd x5, 96(sp) sd x6, 88(sp) sd x7, 80(sp) # ... 其余寄存器同理 ... sd x31, 0(sp) # 准备 C 函数参数第一个参数是陷阱帧指针 mv a0, sp call trap_handler # 陷阱处理函数返回后恢复现场 trap_return: ld x31, 0(sp) # ... 其余寄存器按逆序恢复 ... ld x1, 112(sp) addi sp, sp, 128 ret # 返回到触发陷阱前的现场这段汇编里有几个细节值得单说。第一是压栈偏移量必须保证 16 字节对齐否则在某些模拟器实现里访存会报错第二是trap_handler的返回值通常是一个新的栈指针用来实现系统调用后不再返回原用户程序而是直接切换到另一个进程第三是“恢复现场”必须包含程序计数器所在的那个寄存器少了它整个系统会在返回时跳到全零地址。我的习惯是把这个汇编文件单独编译成目标文件再通过链接脚本固定放在陷阱向量地址上这样模拟器触发中断时才能准确找到它。4.2 进程切换从顺序执行到多道程序系统调用的入口解决了“用户程序怎么进内核”的问题但一个真正的操作系统还需要解决“多个用户程序怎么轮流用 CPU”。教学框架里通常用时钟中断配合时间片轮转来实现定时器每隔若干毫秒发起一次时钟中断操作系统在中断处理里检查当前进程的时间片是否用完如果用完就保存当前进程的现场换入下一个进程。这个“切换现场”的操作是所有并发问题的根源。它必须在汇编层面完成把当前进程的通用寄存器、程序计数器和栈指针保存到该进程的内核栈上再从下一个进程的内核栈里恢复这些寄存器。特别要注意的是进程切换时不只保存几个临时寄存器因为被换出去的进程下次恢复时必须能从上一次被打断的那条指令继续执行仿佛什么都没发生过。// 进程切换核心保存 from 的现场恢复 to 的现场示意 void context_switch(PCB *from, PCB *to) { // 保存当前 CPU 寄存器到 from 的栈上 from-sp save_context(); // 从 to 的栈上恢复寄存器 load_context(to-sp); }这里的save_context和load_context是成对出现的一个把寄存器压栈并返回新栈指针一个从栈上弹栈并恢复寄存器。它们在整个操作系统里只写一次但几乎每个模块都会调用进程创建时初始化一个伪现场调度器切换时交换现场系统调用返回时也可以用它来直接跳转而不是一层层调用返回。我踩过的坑是创建第一个进程时忘记把它的程序计数器设置成入口地址导致调度器第一次切换就跳进了空白内存解决方法是把“模拟一次陷阱返回”的代码复用成进程创建时的初始化模板保证进程首条指令一定是一条中断返回指令。4.3 装载用户程序自己写一遍 ELF 加载器的核心操作系统能调度进程之后最后一个硬骨头是把用户程序装进内存。用户程序不能直接用模拟器认识的裸镜像格式而是带有文件头、程序头、节区表等结构的 ELF。操作系统必须从 ELF 里提取出那些需要装载的段把它们拷贝到内存的正确位置然后把程序计数器设置成 ELF 头里记录的入口地址。写这个加载器不需要解析 ELF 的全部结构只需要处理两种表项程序头里所有PT_LOAD类型的段。每个这类段描述了“文件中的哪一段应该被拷贝到内存的哪个地址”、“要拷贝多长”以及“段在内存里实际占用多长”。这两个长度经常不一致——代码段和已初始化数据段在文件里有内容而 BSS 段在文件里长度为零却要在内存里占一大块空间并且必须清零。// 加载 ELF 中所有 PT_LOAD 段示意返回入口地址 uint32_t load_elf(uint8_t *elf, size_t size) { Elf_Ehdr *ehdr (Elf_Ehdr *)elf; uint32_t entry ehdr-e_entry; Elf_Phdr *phdr (Elf_Phdr *)(elf ehdr-e_phoff); for (int i 0; i ehdr-e_phnum; i) { if (phdr[i].p_type ! PT_LOAD) continue; uint8_t *dst (uint8_t *)(uintptr_t)phdr[i].p_vaddr; uint8_t *src elf phdr[i].p_offset; // 把文件段拷贝到内存 memcpy(dst, src, phdr[i].p_filesz); // 把 BSS 部分清零文件里没有内容但内存里必须置零 size_t bss_size phdr[i].p_memsz - phdr[i].p_filesz; memset(dst phdr[i].p_filesz, 0, bss_size); } return entry; }这段代码是最精简的加载器核心但它藏着一个非常隐蔽的坑p_filesz和p_memsz在 ELF 文件里被定义成 64 位无符号整数如果你在 32 位环境里把它转型成int一旦某个段的 BSS 长度超过 2GB减法结果就会变成负数memset的长度参数会变成一个巨大的无符号数直接写穿整个内存。这个坑在真实系统里几乎不会触发但在教学实验里反而常见因为学生用 32 位编译环境处理 64 位结构体时经常忘记显式转型。我的建议是把所有涉及 ELF 长度的变量统一声明成size_t并在加载前打印一次入口地址和每个段的地址范围确认无误再跳转。5. 这套框架的 6 条避坑记录编译、链接与运行期最容易翻车的地方坑 1链接地址和装载地址不一致程序第一条跳转就“飞了”现象镜像构建成功模拟器启动后屏幕空白单步执行几轮后程序计数器跑到 0x00000000 附近。 原因链接脚本把代码段放在了一个地址而模拟器的物理内存起始地址是另一个地址。跳转指令用的是绝对地址一跳就跳到空内存区。 解决统一以模拟器定义的物理内存起始地址为准回填到链接脚本的ORIGIN。调试时在模拟器的执行循环里打印第一条指令的地址如果它不是预期入口直接确认链接脚本。我的做法是把起始地址定义成 Makefile 里的一个变量模拟器和链接脚本都引用它避免两处手抄数字抄错。坑 2编译优化把外设访问当成普通内存优化掉现象在操作系统里朝串口寄存器连续写入输出时断时续用延时函数等待某个状态位程序直接跳过等待跑飞。 原因GCC 在-O2及以上优化时如果认为某块内存地址没有被读取就会把重复写入合并或者删掉延时循环如果只更新局部变量会被判定为“死代码”整个删除。 解决把映射到外设的地址全部声明成volatile指针延时不要用纯 C 空循环去调用抽象层提供的时钟接口或者写一段内嵌汇编空指令。这是我在这个框架里踩过最多次的坑而且它只在优化等级高的时候出现不加-O0对比根本看不出来。坑 3BSS 段没清零全局变量初始值随机现象某个计数的全局变量一开始是 0但程序跑起来后却被加到一个很大的随机数上行为时好时坏。 原因启动汇编里的 BSS 清零循环写错了范围或者链接脚本里没把 BSS 段收进_bss_start到_bss_end之间。未初始化全局变量被保留在内存里初始值取决于模拟器的内存初始内容可能是任何值。 解决在启动代码里加清零循环并且让链接脚本导出清晰的起止符号。验证方法是在清零循环前后各打印一个_bss_start处的值确认它确实从随机值变成了 0。这个坑的特点是难以稳定复现所以一旦程序行为“偶尔正常、偶尔异常”优先怀疑它。坑 4陷阱入口只保存了一部分寄存器系统调用返回后寄存器错乱现象系统调用能触发内核处理也正常但回到用户程序以后某个局部变量突然变成了垃圾值程序跑到后面才崩溃。 原因陷阱入口和返回路径没有保存全部通用寄存器。用户在调用系统调用时编译器假设某些寄存器会被破坏但如果内核入口破坏的寄存器比调用约定规定的更多返回时现场就成了“脏现场”。 解决陷阱入口的压栈寄存器列表和返回路径的弹栈寄存器列表必须逐条对应一个不漏。建议在汇编里写注释标记每个寄存器的栈偏移弹栈时按偏移逆序核对一遍。还有一种验证方法在返回路径弹栈完成后、真正ret之前打印一遍所有寄存器和进入陷阱前打印的值逐一比对。坑 5改了模拟器代码重新运行却还是旧行为现象明明修改了指令译码逻辑make run之后执行的还是旧行为甚至报错信息还是修复前的。 原因Makefile 没有可靠的头文件依赖跟踪某些关键的.h文件被改后依赖它的源文件不会被强制重新编译或者模拟器进程没有退出旧进程还在占住终端。 解决先确认没有残留模拟器进程再执行make clean make -j$(nproc)全量重编。我自己的习惯是每改一次模拟器代码就在命令行里执行make -B强制重新生成所有目标文件虽然多花几十秒但能省下大量“改了没生效”的困惑时间。坑 6加载 ELF 时 32 位长度和 64 位长度混用内存被写穿现象加载用户程序时memcpy或memset抛错或者加载后的内存区域头部被莫名覆盖。 原因ELF 文件头里段的长度字段是固定宽度直接赋值给 32 位整型后做减法出现负数转换为超大无符号数导致一次拷贝写了几 GB。 解决所有 ELF 解析相关的变量统一用size_t和uint64_t并在加载前校验p_vaddr p_memsz不越过物理内存上边界。代码里加一行边界检查越界时直接报错而不是继续跑能让你在 5 分钟内定位而不是抓瞎半天。6. 从“跑通”到“跑懂”三个能验证你真理解的动手方向这套框架跑通以后最容易陷入的误区是“能运行就觉得会了”。事实上框架自带实现已经把最难的几个点替你铺平了你要做的是打破它、再补全它才能确认自己不是在对着答案抄作业。我的习惯是挑三个方向动手改一改每一步都有明确的验证标准而不是凭感觉“好像懂了”。第一个方向给模拟器增加一条新指令。我通常是加一条“统计 1 的个数”的指令先在模拟器解码表里加入对应操作码再用内嵌汇编在操作系统里调用。验证标准很简单用一个已知数在主机上用 C 算出结果再在模拟器里调用同一算法两份结果必须一致。这个方向能同时检验你对解码格式、寄存器编号和调用约定的理解。第二个方向在抽象层增加一个新设备比如“虚拟时钟”。给操作系统提供一个读取当前时间戳的接口然后让两个用户程序分别依赖时间戳做不同延时观察调度器是否还能公平分配时间片。验证方法是在每个进程切换时打印当前时间戳看两次切换的间隔是否符合预期。这个方向逼着你真正理解中断和设备的耦合关系而不是只在教科书里见过“时钟中断”这四个字。第三个方向自己实现一个系统调用比如“打印一个十六进制数”。从用户程序传参到内核解析参数并驱动串口输出整条链路必须在一个系统调用里完成。验证标准是用户程序调用它后模拟器上能看到格式正确的十六进制输出。这个方向能把陷阱、参数传递、抽象层设备读写三块知识串成一条线。最后说一个我的个人习惯拿到这套框架后先别着急看它自带的操作系统实现而是只把三份接口头文件当作需求文档自己从模拟器开始一路写下来实在跑不动了再回头对照自带实现。这样走一遍你踩过的每个坑都会变成长期记忆里的“手感”。等你再回过头做真实系统上的性能分析或者驱动开发时你会发现当初那套小小框架里的寄存器约定和链接地址竟然处处都是现实系统的缩小版。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/18 22:17:26 · 阅读 1.2k 从模拟器到操作系统：计算机系统教学实验框架全解析
简介南京大学计算机系统课程ICS2017编程作业项目提供了覆盖模拟器、抽象层、操作系统到应用程序的完整教学实验框架其中NEMU负责微处理器模拟NexusAM承担硬件抽象接口NanosLite实现轻量内核NavyApps承载示例应用适合希望夯实计算机系统底层能力的学生或开发者用于课程配套实验与自学。压缩包共877个文件以C语言工程为主体538个c、183个h另含22个cpp、makefile与mkf构建脚本、Markdown笔记、少量汇编源文件、Python辅助工具以及字体和NES游戏镜像等整体仅18.6MB便于下载后快速查阅与编译。目前已有97人学习浏览。使用者可以沿着NEMU逐步实现指令解析与执行再借助NexusAM完成中断和输入输出进而在NanosLite上加载NavyApps中的程序验证系统调用与进程调度形成从硬件到软件的完整闭环。配套的说明文件和可执行脚本也能帮助定位实验难点尤其适合作为计算机系统方向的项目式训练素材。1. 一套能“长出操作系统”的计算机系统教学实验框架它到底在教什么这个标题乍看很长拆开其实只在讲一件事某高校计算机系统课程的教学实验框架把“一台能跑程序的计算机”拆成教学模拟器、硬件抽象层、微型操作系统和用户程序四层压缩包里的就是这四层从零到能跑系统调用的整套脚手架。很多人学系统课程第一反应是去翻开源操作系统内核的源码结果面对百万行代码直接劝退这套框架的思路正好反过来——不是“读操作系统”而是“造操作系统”。你要先在模拟器里让第一条指令跑起来再通过一层薄薄的硬件抽象层把一个只有几条核心机制的小型操作系统“种”出来最后让用户程序在它上面正常打印、退出、调度。这套体系适合三类人被传统“背诵式”系统课劝退的本科生想给学生布置整学期综合实验的高校教师以及所有想亲眼看清指令执行、ELF 装载、上下文切换、系统调用这几件事实际长什么样的从业者。它的价值不在模拟器本身多强大而在四层之间那条清晰的“接缝”——每层都可以被单独修改、单独调试、单独验证。只要沿着这条缝往下走一个只写过 C 语言的人也能在几周内亲手拉起一套完整的小系统。2. 框架三层结构与构建体系模拟器、抽象层、操作系统是怎么咬合的2.1 为什么需要“中间那层抽象”先讲一个真实痛点如果你直接在一个裸模拟器上写操作系统那这个系统天生就和某一种指令集绑死了。换一个 CPU 架构中断控制器要改时钟要改串口输出要改甚至连进程切换时该保存哪些寄存器都要重来。教学实验最忌讳的就是这种“一换平台全盘推翻”的挫败感因为学生根本没精力在两周内同时学会 RISC-V 的调用约定和 x86 的中断门描述符。所以这类框架在模拟器和操作系统之间普遍会插入一个“硬件抽象层”也就是标题里那个抽象层概念。它的定位不是模拟器的一部分也不是操作系统的一部分而是两者之间的一份契约模拟器负责把这些设备的真实行为通过一组固定接口暴露出来操作系统只对着这组接口编程完全不过问底层的寄存器细节。这样做的直接收益是将来想换一种指令集抽象层的接口可以原封不动只要把接口背后的实现换掉上面的操作系统一行都不用改。抽象层该提供哪些能力是这套框架设计里最有讲究的地方。太少了撑不起操作系统太多了又会让实验退化成“照着手册调驱动”。一个合适的边界大致是处理器上下文初始化、物理内存的读写、一个串口或帧缓冲用于输出、一个可编程定时器用来触发时钟中断、外加开关中断和注册中断处理函数的能力。我见过有些框架把磁盘控制器也抽象进去但对教学实验来说反而喧宾夺主学生多半会卡在调试磁盘镜像上而不是理解操作系统。// 抽象层对外接口示意操作系统代码只需要包含这个头文件 #ifndef HAL_H #define HAL_H #include stddef.h #include stdint.h #define HAL_DEV_UART 0 // 串口 #define HAL_DEV_TIMER 1 // 定时器 #define HAL_DEV_FB 2 // 帧缓冲 // 从设备读取 len 字节到 buf返回实际读取的长度 int hal_dev_read(int dev, void *buf, size_t len); // 向设备写入 len 字节返回实际写入的长度 int hal_dev_write(int dev, const void *buf, size_t len); // 开关中断enable1 允许触发返回之前的中断状态 int hal_irq_set_enable(int enable); // 注册一个中断处理函数irq 为中断号 void hal_irq_register(int irq, void (*handler)(void)); // 延时 n 毫秒供轮询类驱动使用 void hal_delay_ms(uint32_t n); #endif这段接口设计里有一个值得注意的细节所有读写都采用“设备号 缓冲区指针 长度”的签名而不是直接给每个设备独立的 read/write 函数。好处是新增设备时不需要改操作系统的调用点只要在 hal 内部加一个 case坏处是参数里少了一个“偏移量”所以这套接口天然适合串口这类顺序读写设备。如果你想把抽象层扩展成支持可寻址的存储型设备建议在签名里再加一个 offset 参数否则后面做虚拟磁盘时接口要重新设计。2.2 工程目录与 Makefile先让框架自带的镜像跑起来拿到压缩包以后第一步不是急着看代码而是把整棵目录树理清楚。典型布局是顶层分出模拟器、抽象层、操作系统、应用程序和构建工具这几个目录外加一个 Makefile 把全部模块串起来。其中模拟器基础设施是纯软件直接在主机上用 GCC 编译即可而从抽象层往下代码最终要跑在模拟器里所以必须用交叉编译器把操作系统的二进制编出来。我拿到这种工程的第一动作永远是先跑一次自带的预编译镜像确认环境没问题再开始动代码。盲目上来就写很容易把“自己代码的 bug”和“工具链问题”混在一起后面查错查到头秃。下面这组命令就是我从零开始跑通整套框架的固定套路# 1. 解压并进入顶层目录 unzip ics-course-framework.zip cd ics-course-framework # 2. 先做一次全量构建生成模拟器可执行文件和操作系统镜像 make clean make -j$(nproc) # 3. 启动模拟器进入交互调试界面 make run这三条命令背后其实藏着一个容易被忽略的规则模拟器本体是主机程序依赖主机 GCC操作系统镜像则是给模拟器“喂”的固件依赖交叉编译工具链。如果你的 make 报错信息指向找不到某个编译器前缀比如riscv64-unknown-elf-gcc说明交叉工具链没有装全这时候返工去调 Makefile 是浪费时间直接补装工具链才是正解。构建成功以后make run会弹出一个带命令行的模拟器界面输入c让它连续运行理论上可以看到操作系统启动后打印出欢迎信息。如果你在make run之后屏幕上什么都没有多半不是模拟器坏了而是镜像的入口地址有问题。此时退回调试界面用si单步执行几轮看程序计数器是不是一开始就跳到了非代码区域。确认环境以后我通常会把模拟器自带的调试指令全部敲一遍info reg看寄存器、x/10 0x80000000看内存、si 10走十步。这个过程相当于给整套系统做一次“体检”也为后面自己加指令和改操作系统打底。2.3 从二进制镜像到“上电启动”一条构建链理解了目录和构建命令接下来值得花十分钟把“从 C 源码到模拟器里的可执行程序”这条链路走清楚。你不必现在就会写链接脚本但你必须知道链接脚本在这套框架里扮演的角色否则后面会遇到“代码明明编译通过了跑起来却像玄学一样随机崩溃”的尴尬场面。整条构建链大致是源码和汇编文件经交叉编译器变成 ELF 目标文件然后用链接脚本把它们按指定地址摆放得到最终的 ELF接下来模拟器并不直接吃 ELF而是用工具把 ELF 转成裸镜像所谓“裸镜像”就是把 ELF 中需要装载到内存的部分原样抠出来拼成一段连续的内存初始内容最后模拟器启动时把这整段内容当作物理内存的初始状态并把程序计数器设置成链接脚本里规定的入口点。这里最关键的一个数字就是“链接地址”。模拟器约定的内存起始地址是 0x80000000那链接脚本就必须把代码段的加载地址也设成 0x80000000。只要这两边不一致第一条跳转指令就会把程序计数器带到空白内存区域结果就是“屏幕什么都不显示单步也看不出规律”。/* 链接脚本片段规定代码段、数据段、BSS 段的装载地址 */ OUTPUT_ARCH(riscv) ENTRY(entry) MEMORY { RAM (RWX) : ORIGIN 0x80000000, LENGTH 128M } SECTIONS { . 0x80000000; .text : { *(.text.entry) *(.text*) } RAM .rodata : { *(.rodata*) } RAM .data : { *(.data*) } RAM .bss : { *(.bss*) } RAM _end .; }链接脚本里值得注意的参数有两个ORIGIN是内存起始地址必须与模拟器的物理内存布局完全一致_end是一个导出符号启动代码会用它来计算 BSS 段范围进而完成清零。我把这个脚本单独拎出来讲是因为它就是“编译通过但运行失败”的最大温床。检验方法很简单在模拟器里打印第一条指令的地址如果和ENTRY指定的入口不一致那问题几乎一定出在这里。3. 从模拟器到抽象层跑通最小可执行程序3.1 最小执行循环让模拟器打印第一条指令整个框架的地基是模拟器它是一个逐条取指、译码、执行指令的循环。理解这个循环你就理解了“CPU 是怎么跑起来的”这个问题的一半。模拟器启动以后把程序计数器设置成 0x80000000然后进入一个死循环从内存读 4 字节当成指令解析出操作码和操作数执行对应的操作再把程序计数器加 4然后重复。分支和跳转指令则直接改写程序计数器从而打断这个线性递增。在它的初始状态下模拟器跑起来是个彻底的黑匣子你不给它加输出你根本不知道它执行到了哪条指令。所以跑通模拟器的第一步就是在这个循环里加一条“打印流水”。// 模拟器核心执行循环位于 simulate.c示意版本 static void cpu_exec(uint64_t n) { for (uint64_t i 0; i n; i) { vaddr_t pc cpu.pc; uint32_t inst vaddr_read(pc, 4); // 从内存读一条指令 exec_inst(inst); // 译码并执行这条指令 cpu.pc 4; // 默认顺序执行 if (trace_enable) { // 打印当前指令地址、机器码和寄存器 0 的值 printf(pc0x%08x inst0x%08x a0%d\n, pc, inst, cpu.gpr[10]); } if (cpu.halt) break; // 遇到停机指令则退出 } }这段代码里有三个参数值得自己调一调。第一个是n它决定本次连续执行多少条指令调试早期建议设置成 1配合单步命令用第二个是trace_enable我的习惯是把它做成命令行参数而不是编译期常量这样不用重新编译就能切换详细输出和安静模式第三个是打印哪几个寄存器前期只打a0和pc就够了等开始调函数调用时再补上ra和sp否则一行输出几十个寄存器反而看不出规律。3.2 抽象层初始化把“裸机”包成一个干净入口模拟器能执行指令以后下一步是把控制权交给抽象层的启动代码。这里面最容易被忽略、也最容易出问题的是“从模拟器跳进操作系统 C 代码之前”那段汇编。模拟器上电时寄存器全部是随机值栈指针尤其不可信如果在没有建立栈的情况下直接调用 C 函数第一个函数调用的返回地址会被压到一个非法地址然后整个系统瞬间崩溃。所以抽象层的入口代码必须在跳进os_main之前把栈、BSS 段和入口条件全部准备好。# 抽象层启动入口模拟器把 pc 设到 _start 之后执行到这里 la sp, _stack_top # 建立栈指针_stack_top 来自链接脚本 la t0, _bss_start # BSS 段起始地址 la t1, _bss_end # BSS 段结束地址 bss_clear_loop: bge t0, t1, bss_clear_done sw zero, 0(t0) # 把 BSS 段逐字清零 addi t0, t0, 4 j bss_clear_loop bss_clear_done: call os_main # 跳进操作系统的 C 入口这段代码在几乎所有教学框架里长得都差不多因为它解决的是一组确定的硬件初始化需求。_stack_top这个符号必须由链接脚本提供通常放在内存最高地址因为栈是向下增长的_bss_start和_bss_end同样来自链接脚本它们圈定的范围必须包含所有未初始化全局变量。BSS 清零这步我见过很多人偷懒跳过后果是某个全局标志位初始值随机程序行为一会儿对一会儿错而且极难复现。这种问题调试起来非常费神所以我的建议是这段汇编一个字节都别省写完就再也不要动它。3.3 加一条自定义指令验证模拟器与抽象层的配合模拟器和抽象层各自能跑通只说明环境没问题还没验证“上下层的契约真的成立”。最干净的验证方式是给模拟器加一条全新的自定义指令然后在抽象层之上的汇编代码里调用它。这样一来你同时动了硬件层、硬件抽象层和测试程序三层只要这条指令能正确执行并回传结果就说明整条链路是通的。以给模拟器加一条“统计一个 32 位整数中 1 的个数”的指令为例。我的做法分三步先在模拟器的译码表里为某个预留操作码加上对应的执行函数然后在抽象层的头文件里用内嵌汇编封装一个函数最后写一个只有几行的测试程序调用这个函数并把结果打印出来。验证标准很明确用主机 GCC 算一遍同样的数两者结果必须一致。// 模拟器中新增指令的执行逻辑示意 static void exec_cnt1(vaddr_t pc, uint32_t inst) { int rd (inst 7) 0x1f; // 目标寄存器编号 int rs1 (inst 15) 0x1f; // 源寄存器编号 uint32_t val cpu.gpr[rs1]; int count 0; for (int i 0; i 32; i) { count (val i) 1; } cpu.gpr[rd] count; }这段逻辑本身不复杂但把它加进模拟器后有两种典型的“验收姿势”。一种是直接看cpu.gpr[rd]在单步执行后的值适合验证指令译码正确另一种是让抽象层封装的函数用 C 语言调用并打印结果适合验证整条工具链和调用约定没问题。我推荐两个都做因为前者能精确定位模拟器的问题后者能暴露抽象层封装时的寄存器误用——常见错误是在内嵌汇编里改坏了某个调用者保存寄存器结果测试函数返回后父函数的局部变量莫名其妙变了。4. 在抽象层上搭建微型操作系统并加载用户程序4.1 系统调用与中断入口操作系统第一次“活”过来有了能执行程序的模拟器和干净的抽象层入口下一步就是让操作系统“活”过来。所谓“活过来”第一个标志是它能够响应中断和异常。操作系统运行在一种特权模式下用户程序运行在另一种模式下两者之间不能直接跳转只能通过一项称为“陷阱”的机制完成切换用户程序发起系统调用或者硬件触发时钟中断处理器停下当前程序跳转到操作系统注册好的入口地址。这个入口是所有操作系统的命门整套上下文保存和恢复逻辑都挤在这几十条汇编指令里。我见过很多初学者在这里翻车保存寄存器时少压了几个返回时就出现“寄存器里凭空多出奇怪值”的灵异现象。正确的顺序是先把所有通用寄存器压栈再切换到内核栈然后调用 C 语言中断处理函数返回时按完全相反的顺序弹栈并把最后一条指令设置成“从陷阱返回”。# 陷阱入口示意进入时已经由硬件切换到内核态 trap_entry: # 先把所有通用寄存器压到当前栈上 addi sp, sp, -128 sd x1, 112(sp) sd x5, 96(sp) sd x6, 88(sp) sd x7, 80(sp) # ... 其余寄存器同理 ... sd x31, 0(sp) # 准备 C 函数参数第一个参数是陷阱帧指针 mv a0, sp call trap_handler # 陷阱处理函数返回后恢复现场 trap_return: ld x31, 0(sp) # ... 其余寄存器按逆序恢复 ... ld x1, 112(sp) addi sp, sp, 128 ret # 返回到触发陷阱前的现场这段汇编里有几个细节值得单说。第一是压栈偏移量必须保证 16 字节对齐否则在某些模拟器实现里访存会报错第二是trap_handler的返回值通常是一个新的栈指针用来实现系统调用后不再返回原用户程序而是直接切换到另一个进程第三是“恢复现场”必须包含程序计数器所在的那个寄存器少了它整个系统会在返回时跳到全零地址。我的习惯是把这个汇编文件单独编译成目标文件再通过链接脚本固定放在陷阱向量地址上这样模拟器触发中断时才能准确找到它。4.2 进程切换从顺序执行到多道程序系统调用的入口解决了“用户程序怎么进内核”的问题但一个真正的操作系统还需要解决“多个用户程序怎么轮流用 CPU”。教学框架里通常用时钟中断配合时间片轮转来实现定时器每隔若干毫秒发起一次时钟中断操作系统在中断处理里检查当前进程的时间片是否用完如果用完就保存当前进程的现场换入下一个进程。这个“切换现场”的操作是所有并发问题的根源。它必须在汇编层面完成把当前进程的通用寄存器、程序计数器和栈指针保存到该进程的内核栈上再从下一个进程的内核栈里恢复这些寄存器。特别要注意的是进程切换时不只保存几个临时寄存器因为被换出去的进程下次恢复时必须能从上一次被打断的那条指令继续执行仿佛什么都没发生过。// 进程切换核心保存 from 的现场恢复 to 的现场示意 void context_switch(PCB *from, PCB *to) { // 保存当前 CPU 寄存器到 from 的栈上 from-sp save_context(); // 从 to 的栈上恢复寄存器 load_context(to-sp); }这里的save_context和load_context是成对出现的一个把寄存器压栈并返回新栈指针一个从栈上弹栈并恢复寄存器。它们在整个操作系统里只写一次但几乎每个模块都会调用进程创建时初始化一个伪现场调度器切换时交换现场系统调用返回时也可以用它来直接跳转而不是一层层调用返回。我踩过的坑是创建第一个进程时忘记把它的程序计数器设置成入口地址导致调度器第一次切换就跳进了空白内存解决方法是把“模拟一次陷阱返回”的代码复用成进程创建时的初始化模板保证进程首条指令一定是一条中断返回指令。4.3 装载用户程序自己写一遍 ELF 加载器的核心操作系统能调度进程之后最后一个硬骨头是把用户程序装进内存。用户程序不能直接用模拟器认识的裸镜像格式而是带有文件头、程序头、节区表等结构的 ELF。操作系统必须从 ELF 里提取出那些需要装载的段把它们拷贝到内存的正确位置然后把程序计数器设置成 ELF 头里记录的入口地址。写这个加载器不需要解析 ELF 的全部结构只需要处理两种表项程序头里所有PT_LOAD类型的段。每个这类段描述了“文件中的哪一段应该被拷贝到内存的哪个地址”、“要拷贝多长”以及“段在内存里实际占用多长”。这两个长度经常不一致——代码段和已初始化数据段在文件里有内容而 BSS 段在文件里长度为零却要在内存里占一大块空间并且必须清零。// 加载 ELF 中所有 PT_LOAD 段示意返回入口地址 uint32_t load_elf(uint8_t *elf, size_t size) { Elf_Ehdr *ehdr (Elf_Ehdr *)elf; uint32_t entry ehdr-e_entry; Elf_Phdr *phdr (Elf_Phdr *)(elf ehdr-e_phoff); for (int i 0; i ehdr-e_phnum; i) { if (phdr[i].p_type ! PT_LOAD) continue; uint8_t *dst (uint8_t *)(uintptr_t)phdr[i].p_vaddr; uint8_t *src elf phdr[i].p_offset; // 把文件段拷贝到内存 memcpy(dst, src, phdr[i].p_filesz); // 把 BSS 部分清零文件里没有内容但内存里必须置零 size_t bss_size phdr[i].p_memsz - phdr[i].p_filesz; memset(dst phdr[i].p_filesz, 0, bss_size); } return entry; }这段代码是最精简的加载器核心但它藏着一个非常隐蔽的坑p_filesz和p_memsz在 ELF 文件里被定义成 64 位无符号整数如果你在 32 位环境里把它转型成int一旦某个段的 BSS 长度超过 2GB减法结果就会变成负数memset的长度参数会变成一个巨大的无符号数直接写穿整个内存。这个坑在真实系统里几乎不会触发但在教学实验里反而常见因为学生用 32 位编译环境处理 64 位结构体时经常忘记显式转型。我的建议是把所有涉及 ELF 长度的变量统一声明成size_t并在加载前打印一次入口地址和每个段的地址范围确认无误再跳转。5. 这套框架的 6 条避坑记录编译、链接与运行期最容易翻车的地方坑 1链接地址和装载地址不一致程序第一条跳转就“飞了”现象镜像构建成功模拟器启动后屏幕空白单步执行几轮后程序计数器跑到 0x00000000 附近。 原因链接脚本把代码段放在了一个地址而模拟器的物理内存起始地址是另一个地址。跳转指令用的是绝对地址一跳就跳到空内存区。 解决统一以模拟器定义的物理内存起始地址为准回填到链接脚本的ORIGIN。调试时在模拟器的执行循环里打印第一条指令的地址如果它不是预期入口直接确认链接脚本。我的做法是把起始地址定义成 Makefile 里的一个变量模拟器和链接脚本都引用它避免两处手抄数字抄错。坑 2编译优化把外设访问当成普通内存优化掉现象在操作系统里朝串口寄存器连续写入输出时断时续用延时函数等待某个状态位程序直接跳过等待跑飞。 原因GCC 在-O2及以上优化时如果认为某块内存地址没有被读取就会把重复写入合并或者删掉延时循环如果只更新局部变量会被判定为“死代码”整个删除。 解决把映射到外设的地址全部声明成volatile指针延时不要用纯 C 空循环去调用抽象层提供的时钟接口或者写一段内嵌汇编空指令。这是我在这个框架里踩过最多次的坑而且它只在优化等级高的时候出现不加-O0对比根本看不出来。坑 3BSS 段没清零全局变量初始值随机现象某个计数的全局变量一开始是 0但程序跑起来后却被加到一个很大的随机数上行为时好时坏。 原因启动汇编里的 BSS 清零循环写错了范围或者链接脚本里没把 BSS 段收进_bss_start到_bss_end之间。未初始化全局变量被保留在内存里初始值取决于模拟器的内存初始内容可能是任何值。 解决在启动代码里加清零循环并且让链接脚本导出清晰的起止符号。验证方法是在清零循环前后各打印一个_bss_start处的值确认它确实从随机值变成了 0。这个坑的特点是难以稳定复现所以一旦程序行为“偶尔正常、偶尔异常”优先怀疑它。坑 4陷阱入口只保存了一部分寄存器系统调用返回后寄存器错乱现象系统调用能触发内核处理也正常但回到用户程序以后某个局部变量突然变成了垃圾值程序跑到后面才崩溃。 原因陷阱入口和返回路径没有保存全部通用寄存器。用户在调用系统调用时编译器假设某些寄存器会被破坏但如果内核入口破坏的寄存器比调用约定规定的更多返回时现场就成了“脏现场”。 解决陷阱入口的压栈寄存器列表和返回路径的弹栈寄存器列表必须逐条对应一个不漏。建议在汇编里写注释标记每个寄存器的栈偏移弹栈时按偏移逆序核对一遍。还有一种验证方法在返回路径弹栈完成后、真正ret之前打印一遍所有寄存器和进入陷阱前打印的值逐一比对。坑 5改了模拟器代码重新运行却还是旧行为现象明明修改了指令译码逻辑make run之后执行的还是旧行为甚至报错信息还是修复前的。 原因Makefile 没有可靠的头文件依赖跟踪某些关键的.h文件被改后依赖它的源文件不会被强制重新编译或者模拟器进程没有退出旧进程还在占住终端。 解决先确认没有残留模拟器进程再执行make clean make -j$(nproc)全量重编。我自己的习惯是每改一次模拟器代码就在命令行里执行make -B强制重新生成所有目标文件虽然多花几十秒但能省下大量“改了没生效”的困惑时间。坑 6加载 ELF 时 32 位长度和 64 位长度混用内存被写穿现象加载用户程序时memcpy或memset抛错或者加载后的内存区域头部被莫名覆盖。 原因ELF 文件头里段的长度字段是固定宽度直接赋值给 32 位整型后做减法出现负数转换为超大无符号数导致一次拷贝写了几 GB。 解决所有 ELF 解析相关的变量统一用size_t和uint64_t并在加载前校验p_vaddr p_memsz不越过物理内存上边界。代码里加一行边界检查越界时直接报错而不是继续跑能让你在 5 分钟内定位而不是抓瞎半天。6. 从“跑通”到“跑懂”三个能验证你真理解的动手方向这套框架跑通以后最容易陷入的误区是“能运行就觉得会了”。事实上框架自带实现已经把最难的几个点替你铺平了你要做的是打破它、再补全它才能确认自己不是在对着答案抄作业。我的习惯是挑三个方向动手改一改每一步都有明确的验证标准而不是凭感觉“好像懂了”。第一个方向给模拟器增加一条新指令。我通常是加一条“统计 1 的个数”的指令先在模拟器解码表里加入对应操作码再用内嵌汇编在操作系统里调用。验证标准很简单用一个已知数在主机上用 C 算出结果再在模拟器里调用同一算法两份结果必须一致。这个方向能同时检验你对解码格式、寄存器编号和调用约定的理解。第二个方向在抽象层增加一个新设备比如“虚拟时钟”。给操作系统提供一个读取当前时间戳的接口然后让两个用户程序分别依赖时间戳做不同延时观察调度器是否还能公平分配时间片。验证方法是在每个进程切换时打印当前时间戳看两次切换的间隔是否符合预期。这个方向逼着你真正理解中断和设备的耦合关系而不是只在教科书里见过“时钟中断”这四个字。第三个方向自己实现一个系统调用比如“打印一个十六进制数”。从用户程序传参到内核解析参数并驱动串口输出整条链路必须在一个系统调用里完成。验证标准是用户程序调用它后模拟器上能看到格式正确的十六进制输出。这个方向能把陷阱、参数传递、抽象层设备读写三块知识串成一条线。最后说一个我的个人习惯拿到这套框架后先别着急看它自带的操作系统实现而是只把三份接口头文件当作需求文档自己从模拟器开始一路写下来实在跑不动了再回头对照自带实现。这样走一遍你踩过的每个坑都会变成长期记忆里的“手感”。等你再回过头做真实系统上的性能分析或者驱动开发时你会发现当初那套小小框架里的寄存器约定和链接地址竟然处处都是现实系统的缩小版。希望帮到你。本文还有配套的精品资源点击获取