第一关：时钟中断的发生

作答要求：

根据相关知识进行实际操作，一直输入 c 直到 0/1 将第一行完全填满。回答问题：当第一行 0/1 字符全部输出完毕的时候一共发生了几次时钟中断，即第一行完全填满时 jiffies 记录的已发生次数为多少？

一、设置版本1内核为分析对象

首先解压版本1内核源码。使用cp命令将/data/workspace/myshixun/exp1中的1.tgz复制到~/os/目录下；

切换到~/os/linux-0.11-lab目录下，将1.tgz解压到当前目录下；

然后调整cur的指向。先使用rm -rf cur将cur删除，再使用ln命令创建符号链接。

现在可以编译和测试版本 1 内核。首先进入1/linux目录下编译内核；

然后回到目录~/os/linux-0.11-lab，并使用./run启动虚拟机检测内核是否正常；

如果正常虚拟机在加载完毕之后将会出现如下画面。

二、开始使用 gdb 调试内核

先关闭bochs虚拟机，然后打开两个终端，其中一个终端在linux-0.11-lab目录下运行rungdb脚本，以启动 bochs 虚拟机并等待 gdb 连接；

在另一个终端里切换到目录~/os/linux-0.11-lab/，然后启动脚本./mygdb，这个命令会启动 gdb 并读入内核符号信息，同时会通过执行0.gdb中的调试命令来连接到 bochs 虚拟机，并进而跟踪到 main 函数入口。

三、跟踪分析时钟中断

等待 gdb 完全启动之后可以在函数 do_timer（由时钟中断的处理函数 timer_interrupt 调用）处设置断点；让程序继续运行（使用命令 c ）,分析在输出第一行 0/1 字符的过程中断点 do_timer 出现的次数，此即为时钟中断的次数。通过全局变量jiffies可以直接查看已发生的时钟中断的次数。

例如，当第 2 个时钟中断发生时系统状态如下所示：

一直输入 c 直到 0/1 将第一行完全填满，如图所示

第2关：第一次时钟中断

根据相关知识分析第一次时钟中断的恢复点的地址是多少，并将答案填写在/data/workspace/myshixun/恢复点指令地址.txt中。

准备阶段

本关卡的分析对象是版本1内核，可以基于前一关卡环境进行后续实验，如果重置实验环境则需要重新将版本1内核设置为分析对象，详见第一关的相关知识。

使用 gdb 调试内核

启动两个终端，在一个终端里切换到目录~/os/linux-0.11-lab，然后运行脚本 rungdb，以启动 bochs 虚拟机并等待 gdb 连接；在另一个终端里切换到目录~/os/linux-0.11-lab，然后执行脚本./mygdb，以启动 gdb 并读入符号信息,跟踪到 main 函数入口。

./rungdb

./mygdb

跟踪分析时钟中断

在函数 do_timer（由时钟中断的处理函数 timer_interrupt 调用）处设置断点；跟踪到该断点第 1 次出现；

b do_timer
c

中断/异常的恢复点分析

当一个中断/异常被 gdb 捕获时，通常正在运行中断处理程序，这时可以继续跟踪，直至回到恢复点指令。以时钟中断为例，为了从函数 do_timer 跟踪到恢复点，可以如下操作：

bt

时钟中断处理程序的入口是 timer_interrupt 函数。跟踪到当前函数（do_timer）执行完毕返回到 timer_interrupt 函数；

finish

跟踪到 timer_interrupt 函数（用汇编语言写的）末尾的 iret 指令；

disas
si
si
disas

b *0x77dd
c
si

得到恢复点地址为0x796c