简介华北电力大学操作系统实验报告共1个doc文档大小约788KB内容围绕操作系统集成实验环境OS Lab的使用与EOS操作系统内核的编译调试展开适合正在学习操作系统课程、需要完成同类实验的本科生参考。报告完整记录了从启动OS Lab、注册用户信息到新建Windows控制台应用程序项目、生成并执行项目的全过程并通过断点中断、单步调试、快速监视、调用堆栈等方式演示了常用调试手法。文中还按实验目的、预备知识、操作步骤逐层展开包含实验环境布局、项目模板选择等细节对源代码生成可执行文件、写入软盘镜像并启动执行的流程解释得比较清晰。已有1361人学习下载可用于操作系统实验环节的对照操作与查漏补缺尤其适合不熟悉OS Lab界面的读者按步骤上手。1. 操作系统实验环境这份 OS Lab EOS 实验报告为什么值得照着做一遍操作系统原理课最尴尬的环节就是实验——书上的进程、信号量、页表讲得头头是道真到动手写代码时连内核长什么样都不知道。这份操作系统实验报告以 OS Lab 集成环境和 EOS 教学操作系统为基底把八个核心实验串成了一条完整的动手线从编译内核、用 Bochs 跟踪启动流程到创建进程、调试线程切换、信号量同步、时间片轮转最后落到二级页表的 CR3 寄存器和页目录项映射。它不是泛泛的课程设计文档而是一套能直接照着敲的复现路径每个实验都明确写了在哪行代码下断点、用什么命令看结果、改哪个函数体。适合刚上完操作系统理论课、需要完成课程实验的本科生也适合想把进程调度和内存管理往实处再推一遍的开发者。整份资源的核心价值在于把抽象的内核机制压缩成了可执行的调试动作。2. OS Lab 环境与 EOS 工程结构先搞懂这套工具链再动手2.1 OS Lab 的组成与工作流从源码到软盘镜像的完整链路OS Lab 不是普通的 IDE它是专门为 EOS 教学内核设计的集成实验环境。启动后你会看到主窗口由菜单栏、工具栏、左侧项目管理器、底部输出窗口和中间编辑器区域构成。第一次启动会弹注册对话框需要填学号和姓名——这个信息最终会写进实验数据文件也就是 OUD 文件所以别随手填。这套环境的核心工作流可以拆成四步新建项目、生成项目、执行、调试。新建项目时有三种模板可选Windows 控制台应用程序、EOS Kernel、EOS 应用程序。控制台应用跑在 Windows 用户态用于练习通用调试技巧EOS Kernel 生成的是内核二进制EOS 应用程序生成的是跑在 EOS 内核之上的用户进程。用 F7 触发生成源代码被编译成 boot.bin、loader.bin、kernel.dll 三个内核可执行文件以及 EOSApp.exe 这样的应用可执行文件。OS Lab 会在启动调试时把这些文件写入 Floppy.img 软盘镜像引导扇区放 boot.bin文件系统区域放 loader.bin 和 kernel.dll。2.2 控制台应用调试四板斧断点、逐过程、监视、调用堆栈第一个实验的全部目的是让你熟练使用调试器。操作路径是这样的右键源文件节点选择添加中的添加新文件模板选C 源文件命名 func.c。然后按照以下步骤练习// func.c - 用于练习调试的最小示例 #include stdio.h void Func() { printf(Hello from Func!\n); } int main() { int n 0; // 在这行插入断点观察变量的初始随机值 n 42; // 单步执行后 n 变为 42 Func(); // 逐语句进入观察调用堆栈的变化 return 0; }# 调试操作对应的快捷键与菜单路径 F5 # 启动调试运行到第一个断点 F10 # 逐过程不进入函数内部 F11 # 逐语句进入函数内部 CtrlF5 # 开始执行不调试直接运行调试的核心要点在于理解三种查看变量的方式鼠标悬停只能看单值快照适合临时确认快速监视对话框适合一次性深入查看结构体添加监视则能把变量钉在监视窗口面板里持续跟踪。在实际调试内核代码时监视窗口是主力工具尤其是跟踪像 PspCreateProcessEnvironment 这样的大函数内部状态变化时变量的实时更新比打日志高效得多。调用堆栈窗口是理解函数调用关系的关键。当我按 F11 进入 Func 函数后堆栈窗口会显示两个帧栈顶是 Func栈底是 main调试器还会标出每个函数的参数值和返回地址。这个视角在后续调试内核启动流程时极其重要因为内核代码的调用层级更深。2.3 EOS 内核项目的三种远程目标机EOS Kernel 项目在调试时依赖远程目标机机制。右键项目节点打开属性页能看到一个关键属性叫远程目标机可选值包括 BCoS 模拟器、Virtual PC 等虚拟化方案。如果目标是调试 BIOS 程序和引导扇区代码必须把值切换为Bochs Debug——只有 Bochs 支持在实模式与保护模式切换的边界处精确断下这是 EOS 启动实验的前提。默认的远程目标机未必支持引导扇区级调试。Bochs Debug 模式启动后输入 sreg 可以查看段寄存器状态输入 r 查看通用寄存器值。如果你不做任何修改直接调试会在 KiSystemStartup 函数的 KiInitializePic 调用处停下来。项目生成的产物值得打开看一眼。生成完成后用资源管理器打开项目目录下的 debug 文件夹能看到 boot.bin512 字节引导扇区、loader.bin加载器和 kernel.dll内核主体。这三个文件的协作关系是BIOS 读引导扇区 → boot.bin 加载 loader.bin → loader.bin 把 kernel.dll 放入内存并跳转执行。3. 从启动跟踪到进程创建在内核代码里下断点3.1 用 Bochs 调试 BIOS 与引导程序看懂实模式下的启动链路操作系统的启动过程是所有后续实验的地基。这个实验的核心工具是 Bochs 虚拟机的调试命令OS Lab 集成了一个 Console 窗口专门与 Bochs 交互。调试启动流程时先确认项目属性中远程目标机已设置为Bochs Debug然后按 F7 生成项目确保 boot.asm 和 loader.asm 两个 NASM 汇编源文件被正确编译。启动调试后在 Console 窗口输入调试命令逐步观察启动状态sreg # 显示当前段寄存器状态确认 CS:IP 指向 BIOS 入口 r # 查看通用寄存器值观察 CPU 加电后的初始状态 info cpu # 查看 CPU 完整状态包括标志寄存器编译 EOS 引导程序的核心是 NASM 汇编。boot.asm 是一个标准的引导扇区程序以 0x7C00 为加载地址最后以 0x55AA 引导标志结尾。loader.asm 的职责是切换到保护模式设置 GDT 和段寄存器然后把控制权转交给 kernel.dll。如果你对汇编不熟可以先只阅读注释部分把关注点放在两条链路上boot.bin 如何被 BIOS 加载loader.bin 如何在保护模式下建立执行环境。常见做法是在 KiSystemStartup 函数入口下第一个断点。这个函数是 EOS 内核执行的起点位于 ke 文件夹的 start.c 文件中。断点命中后单步执行到第 61 行的 KiInitializePic 调用处从这里开始都是内核初始化中断控制器的代码。随后你可以通过 Console 窗口继续输入调试命令来验证内存布局而不是直接跳转到函数结束。3.2 CreateProcess 的调用链从用户 API 到内核进程工厂进程创建实验揭示了操作系统课程里进程是资源分配单位这一抽象概念的具体化过程。整个链条从应用程序调用 CreateProcess 开始一直深入到内核的 PsCreateProcess 函数。实验的操作路径很明确先在 EOS 应用程序项目中替换 EOSApp.c 为 NewProc.c按 F5 启动调试在弹出的调试异常对话框中选择否继续执行让父进程创建子进程然后在调用 CreateProcess 的代码行下断点。要看到完整调用链需要按 F11 逐语句跟踪。进入内核后找到 create.c 文件第 163 行的 PspCreateProcessEnvironment 调用处在这里再下一个断点。此时调用堆栈窗口会展示完整的调用路径从 CreateProcess 到内核分发函数再到 PsCreateProcess 和 PspCreateProcessEnvironment。// NewProc.c - CreateProcess 调用与内核调试的入口 #include EOS.h void main() { int pid; char *cmdLine Hello.exe; // 要创建的子进程可执行文件名 // 第57行在这行设置断点跟踪进入内核 pid CreateProcess(cmdLine, NULL, NULL, 0); if (pid 0) { printf(Child process created, pid %d\n, pid); } else { printf(CreateProcess failed\n); } // 添加第二个断点在程序末尾观察子进程是否正常运行 Sleep(5000); }调用链完整路径通过调用堆栈窗口观察 main → CreateProcess用户态 API→ 内核系统调用分发 → PsCreateProcess → PspCreateProcessEnvironment复制父进程环境、建立地址空间理解 CreateProcess 的参数是参与这个实验的基本功。第一个 cmdLine 参数是要加载的可执行文件路径第二个参数传 NULL 表示不显式指定安全属性第三个参数设计为线程安全属性但因为 EOS 是教学内核所以被忽略第四个参数是创建标志0 表示默认行为。进程创建完毕后子进程的代码和数据段会被加载到独立地址空间这正好为后面的内存管理实验提供了观察场景。3.3 多进程并发用 NewTwoProc.c 验证独立地址空间单进程创建实验做完后可以进一步把 EOSApp.c 替换为 NewTwoProc.c这个参考源代码同时创建两个子进程用于验证多进程并发行为。生成启动后观察两个子进程交替输出内容这就是分时系统的基本表现。关于调试异常对话框的选择逻辑需要特别说明选择是会把控制权交给调试器让你在用户态断点处停下选择否则直接以不调试模式运行。进程创建实验的惯例是先选否跑通流程再选是进内核跟踪。// NewTwoProc.c - 创建两个子进程并观察并发执行 #include EOS.h void main() { int pid1, pid2; pid1 CreateProcess(Hello.exe, NULL, NULL, 0); pid2 CreateProcess(Hello.exe, NULL, NULL, 0); if (pid1 0 pid2 0) { printf(Two processes created: %d, %d\n, pid1, pid2); } Sleep(10000); }注意这里两个进程虽然加载同一个 Hello.exe但各自的地址空间是独立拷贝的。每个进程有独立的页目录和页表逻辑地址相同但物理地址不同这是理解进程隔离的关键。4. 线程状态转换、信号量同步与时间片轮转内核算法级调试4.1 用 loop 命令观察线程状态流转的四条路径线程实验的核心手段是 EOS 控制台命令 loop。执行后该命令会创建一个循环线程并持续输出计数。配合断点调试就能精确观察线程在就绪、运行、阻塞三种状态间的切换过程。loop # 在控制台1创建loop线程持续输出执行计数 CtrlF2 # 切换到控制台2 suspend 31 # 挂起ID为31的loop线程 CtrlF1 # 切回控制台1观察计数是否停止增长转移路径需要理解四条核心分支从阻塞到就绪的唤醒路径典型场景是线程等待的资源被释放后进入就绪队列从运行到就绪的抢占或时间片到期路径从就绪到运行的调度器选择路径从运行到阻塞的等待事件路径。在 PspSelectNextThread 函数中设置断点可以看到调度器是如何在当前线程被抢先时切换上下文的。4.2 为 EOS 增加挂起状态线程状态机的扩展实践EOS 原有线程状态已经包含了阻塞、就绪、运行但这个实验要求你新增挂起状态。挂起与阻塞的区别在于阻塞是线程主动等待资源挂起是被外部命令强制暂停与资源无关。为了实现挂起你需要在线程控制块中增加一个 SuspendCount 字段当该值大于 0 时调度器不选择该线程执行。该实验的操作路径是在控制台执行 loop 记录线程 ID然后切换控制台执行 suspend 命令。挂起成功后切回原控制台如果计数停止增长说明挂起逻辑生效。实现层面的关键是修改调度器的可运行判断条件在 PspSelectNextThread 中排除 SuspendCount 0 的线程。4.3 信号量等待超时与批量释放修改内核源码的完整样例生产者-消费者问题是进程同步实验的经典载体。EOS 的信号量默认行为很简单PsWaitForSemaphore 的等待时间是 INFINITEPsReleaseSemaphore 的释放数量是 1。实验要求修改这两个函数让超时等待和批量释放真正生效。// semaphore.c - 修改后的等待与释放逻辑代码片段 // 返回值说明成功返回 0超时返回特定错误码 // 批量释放的核心逻辑 int PsReleaseSemaphore(PS_SEMAPHORE *Semaphore, int ReleaseCount) { int i; for (i 0; i ReleaseCount; i) { // 单次释放信号量计数 Semaphore-Count; } // 批量唤醒等待队列中的线程 for (i 0; i ReleaseCount; i) { if (Semaphore-WaitQueue.Count 0) { WakeUpOneThread(Semaphore-WaitQueue); // 按FIFO唤醒一个等待线程 } } }等待超时功能的实现需要用到 EOS 的定时器机制。在等待函数中设置一个超时时间如果在该时间内信号量未被释放则返回超时错误。这比直接循环等待复杂得多因为它要求内核能在等待期间响应时钟中断并在超时时刻把线程拉回就绪队列。4.4 时间片轮转的核心算法PspRoundRobin 的改造EOS 默认调度策略是基于优先级的抢先式调度不涉及时间片。这在控制台命令 rr 的执行结果中表现很明显同优先级的线程一旦获得 CPU 就不会主动让出导致第一个线程独占执行。实验任务是修改 ps/sched.c 第 337 行的 PspRoundRobin 函数实现真正的时间片轮转。// sched.c - PspRoundRobin 函数改造的核心逻辑 void PspRoundRobin() { // 每产生一次时钟中断就会调用该函数 // 如果存在多个同优先级就绪线程才有轮转的必要 if (在就绪队列中同优先级线程数量 1) { // 记录当前线程已占用CPU的时间 CurrentThread-CpuTime; // 达到时间片上限时主动让出CPU if (CurrentThread-CpuTime TIME_SLICE) { CurrentThread-CpuTime 0; // 把当前线程移到同优先级队列尾部 MoveToTail(CurrentThread); // 触发一次重新调度 PspScheduleNextThread(); } } }修改完成后重新生成内核按 F5 启动调试输入 rr 命令应该能看到 20 个线程轮流执行的效果。如果还是只有一个线程跑到底问题大概率出在时钟中断没有正确触发 PspRoundRobin或者在让出 CPU 后重新选中的还是同一个线程。实现说明TIME_SLICE 的值需要按系统时钟周期换算——如果时钟中断每 10ms 触发一次你希望每个线程运行 100ms那么 TIME_SLICE 就应该设为 10。CpuTime 字段需要在线程控制块中新增并在线程被选中执行时清零。5. EOS 调试与内存管理避坑指南命令行、断点与页表的实战教训5.1 断点加不上或不生效检查符号加载状态现象在某行代码上添加断点时红色圆点正常出现但启动调试后箭头直接跳过断点完全不中断。原因EOS Kernel 项目默认使用 Debug 配置生成但如果你之前切到了 Release 配置生成的二进制文件不带调试符号。OS Lab 的断点机制依赖符号表解析源代码行号没有符号就无法定位。解决确认当前活动项目配置是 Debug。点击工具栏的项目配置下拉列表选择Debug。重新按 F7 生成项目再启动调试。5.2 软盘镜像文件列表里找不到 boot.bin现象用 FloppyImageEditor 打开 Floppy.img文件列表中只能看到 loader.bin 和 kernel.dll但 boot.bin 找不到。原因boot.bin 被写入软盘的引导扇区也就是第 0 扇区该区域不受文件系统管理。FloppyImageEditor 的文件列表展示的是 FAT12 文件系统的文件目录不会包含引导扇区内容。解决无需解决这是预期行为。要验证 boot.bin 是否存在可以用十六进制方式查看镜像文件的第一个扇区或者直接看生成信息确认 boot.bin 已成功编译。5.3 EOS 应用调试时出现调试异常对话框选错选项导致进不了用户代码现象按 F5 启动调试 EOS 应用程序时弹出一个调试异常对话框选择后要么卡在内核里要么直接跑完看不到调试效果。原因EOS 应用运行在内核之上启动调试时会先触发一次内核级异常。解决如果你要调试应用程序本身的代码比如跟踪 CreateProcess选择是进入异常调试后再去用户代码行设置断点如果你只是想运行看效果选否直接继续。两种情况没有对错选择标准是你调试的目标在哪一层。5.4 内存分配相关的 pm 命令结果不变化修改了代码但没替换旧实现现象按照实验指导修改 pm.c 后重新生成并执行 pm 命令物理内存使用情况还是原来的样子。原因实验提供了修改后的 pm.c 文件你需要用其中的 ConsoleCmdPhysicalMemory 函数体替换 ke/sysproc.c 文件中对应函数的函数体而不是把整个文件拖进去覆盖。解决用文本方式打开实验文件夹里的 pm.c找到 ConsoleCmdPhysicalMemory 函数复制其函数体粘贴到 sysproc.c 中同名函数的内部。如果粘贴后出现编译错误多半是括号配对问题。5.5 二级页表映射信息看不懂CR3 寄存器与页目录项的关系混乱现象实验 8 要求查看进程的页目录和页表映射信息使用 getcr3.asm 获取 CR3 值但输出的映射信息看不懂。原因i386 处理器使用二级页表结构CR3 指向页目录基地址。页目录的每个表项指向一个页表页表的每个表项指向一个物理页。EOS 输出信息时PDE 和 PTE 是分开输出的需要同时观察。解决先读输出的页目录项找到状态为 Present 的 PDE根据其物理地址定位页表再读对应的页表项确认映射的目标物理地址。实验要求你把输出内容复制到文本文件对比用两列对齐法检查映射关系即可。6. 用 mm 与 vm 命令交叉验证进程地址空间映射的正确性当你完成内存管理相关实验后需要一套方法来验证你的修改是否正确。我的惯用做法是同时开两个控制台一个跑 EOS 应用程序另一个跑内核命令。在应用的控制台里启动 EOSApp.exe它等待十秒这十秒足够你在另一个控制台输入 mm 命令查看系统进程的二级页表映射。你可以同时按下 CtrlF2 切换控制台并输入 mm把系统进程的页表信息打印出来和应用程序自己的映射信息对比。对照两者的页表映射数据判断标准是系统进程和应用程序进程的页目录基地址不同用户态地址空间大多映射到不同的物理页内核态地址空间通常映射到相同的物理页。如果在你的输出中两个进程的 PDE 完全相同说明地址空间隔离失效了问题出在 PspCreateProcessEnvironment 复制页表时没有按进程区分页目录。另一种做法是用 vm 命令跟踪进程虚拟地址描述符。在创建应用程序进程之前执行 vm记录系统进程的虚拟地址空间分布创建应用程序进程后再执行 vm观察新进程的地址空间分配情况。在应用程序进程内分配虚拟页后再用 vm 查看你会看到动态分配的地址段被标记为已提交状态。# 常用的三个验证命令组合 pm # 物理页分配与回收状态检查 vm # 进程虚拟地址空间分布检查 mm # 二级页表映射完整性检查组合使用场景 1. 修改调度算法后 - 输入 rr观察20个线程是否轮流执行 2. 修改信号量实现后 - 运行生产者消费者程序观察是否出现死锁 3. 修改内存分配后 - 先跑 pm再跑 vm确认地址空间分配正确一个经验之谈每完成一个内核改动不要直接进入下一个实验先用上述命令组合做一轮回归。调度器改完后测 rr信号量改完后测生产者消费者内存改完后测 pm 和 vm。这样做能避免问题堆叠到后面实验里无从排错。从那以后我每次改完内核源码都会强制走一遍生成 → 启动 → 敲对应控制台命令 → 查看输出的循环用固定的命令序列做验证。这套资源里的八个实验真正价值在于它们是一套完整的内核调试训练路径。希望帮到你。本文还有配套的精品资源点击获取