实验二操作系统的启动资料.docx
《实验二操作系统的启动资料.docx》由会员分享，可在线阅读，更多相关《实验二操作系统的启动资料.docx（15页珍藏版）》请在冰豆网上搜索。
实验二操作系统的启动资料
上海应用技术学院
程序设计语言实验报告
实验名称
操作系统的启动
实验序号
实验二
实验日期
姓名
学号
指导教师
专业
计算机科学与技术
班级
成绩
1、实验目的及要求
跟踪调试EOS在PC机上从加电复位到成功启动的全过程，了解操作系统的启动过程。
2、实验环境
WindowsXP；TevationOSLab。
3、实验内容
1准备实验
1.启动OSLab。
2.新建一个EOSKernel项目。
3.在“项目管理器”窗口中打开boot文件夹中的boot.asm和loader.asm两个汇编文件。
boot.asm是软盘引导扇区程序的源文件，loader.asm是loader程序的源文件。
简单阅读一下这两个文件中的NASM汇编代码和注释。
4.按F7生成项目。
如图1.
图1.
5.生成完成后，使用Windows资源管理器打开项目文件夹中的Debug文件夹。
找到由boot.asm生成的软盘引导扇区程序boot.bin文件，该文件的大小一定为512字节（与软盘引导扇区的大小一致）；找到由loader.asm生成的loader程序loader.bin文件，记录下此文件的大小（如图2），在下面的实验中会用到；找到由其它源文件生成的操作系统内核文件kernel.dll。
如图3。
图2
图3
2调试EOS操作系统的启动过程
2.1使用Bochs做为远程目标机
按照下面的步骤将调试时使用的远程目标机修改为Bochs：
1.在“项目管理器”窗口中，右键点击目录树的根节点（kernel），选择快捷菜单中的“属性”，弹出项目的“属性页”对话框（此时按F1可以获得关于属性页的帮助）。
2.在弹出的“属性页”对话框右侧的属性列表中找到“远程目标机”属性，将此属性值修改为“BochsDebug”（此时按F1可以获得关于此属性的帮助）。
3.点击“确定”按钮关闭“属性页”对话框。
接下来就可以使用Bochs模拟器调试BIOS程序和软盘引导扇区程序了。
4.结果如图4。
图4
2.2调试BIOS程序
按F5启动调试，此时会弹出两个Bochs窗口。
标题为“Bochsforwindows-Display”的窗口（如图5）相当于计算机的显示器，显示操作系统的输出；标题为“Bochsforwindows-Console”的窗口（如图6）是Bochs的控制台，用来输入调试命令，输出各种调试信息。
图5
图6
启动调试后，Bochs在CPU要执行的第一条指令（即BIOS的第一条指令）处中断，此时，Display窗口没有显示任何内容，Console窗口显示要执行的BIOS第一条指令的相关信息，并等待用户输入调试命令，如图7：
图7
从Console窗口显示的内容中，我们可以获得关于BIOS第一条指令的如下信息：
●行首的[0xfffffff0]表示此条指令所在的物理地址。
●f000:
fff0表示此条指令所在的逻辑地址（段地址:
偏移地址）。
●jmpfarf000:
e05b是此条指令的反汇编代码。
●行尾的ea5be000f0是此条指令的十六进制字节码，可以看出此条指令有5个字节。
接下来可以按照下面的步骤查看CPU在没有执行任何指令之前主要寄存器和内存中的数据：
1.在Console窗口中输入调试命令sreg后按回车，显示当前CPU中各个段寄存器的值，如图8。
其中CS寄存器信息行中的“s=0xf000”表示CS寄存器的值为0xf000。
图8
2.输入调试命令r后按回车，显示当前CPU中各个通用寄存器的值，如图9。
其中“rip:
0x00000000:
0000fff0”表示IP寄存器的值为0xfff0。
图9
输入调试命令xp/1024b0x0000，查看开始的1024个字节的物理内存。
在Console中输出的这1K物理内存的值都为0，如图10。
说明BIOS中断向量表还没有被加载到此处。
图10
3.输入调试命令xp/512b0x7c00，查看软盘引导扇区应该被加载到的内存位置。
输出的内存值都为0，如图11,。
说明软盘引导扇区还没有被加载到此处。
可以验证BIOS第一条指令所在逻辑地址中的段地址和CS寄存器值是一致的，偏移地址和IP寄存器的值是一致的。
由于内存还没有被使用，所以其中的值都为0。
图11
2.3调试软盘引导扇区程序
BIOS在执行完自检和初始化程序后，会将软盘引导扇区加载到物理地址0x7c00-0x7dff处，并从0x7c00处的指令开始执行引导程序，所以接下来练习从0x7c00处开始调试软盘引导扇区程序：
1.输入调试命令vb0x0000:
0x7c00，这样就在逻辑地址0x0000:
0x7c00（相当于物理地址0x7c00）处添加了一个断点如图12。
图12
2.输入调试命令c继续执行，在0x7c00处的断点中断如图13。
图13
中断后会在Console窗口中输出下一个要执行的指令，即软盘引导扇区程序的第一条指令如图14。
（0）[0x00007c00]0000:
7c00（unk.ctxt）:
jmp.+0x006d（0x00007c6f）;eb6d
图14
3.为了方便后面的使用，先在纸上分别记录下此条指令的字节码（eb6d）和此条指令要跳转执行的下一条指令的地址（括号中的0x00007c6f）。
4.输入调试命令sreg验证CS寄存器（0x0000）的值。
如图15。
图15.
5.调试命令r验证IP寄存器（0x7c00）的值。
如图16。
图16
6.由于BIOS程序此时已经执行完毕，输入调试命令xp/1024b0x0000验证此时BIOS中断向量表已经被载入。
如图17。
图17
7.输入调试命令xp/512b0x7c00显示软盘引导扇区程序的所有字节码。
观察此块内存最开始的两个字节分别为0xeb和0x6d，这和引导程序第一条指令的字节码（eb6d）是相同的。
此块内存最后的两个字节分别为0x55和0xaa（如图18-19），
图18
图19
表示引导扇区是激活的，可以用来引导操作系统，这两个字节是boot.asm中最后一行语句
dw0xaa55
定义的（注意，Intel80386CPU使用littleendian字节顺序）。
8.输入调试命令xp/512b0x0600验证第一个用户可用区域是空白的。
如图20。
图20
9.输入调试命令xp/512b0x7e00验证第二个用户可用区域是空白的。
如图21。
图21
10.自己设计两个查看内存的调试命令，分别验证这两个用户可用区域的高地址端也是空白的。
如图22。
图22
11.输入调试命令xp/512b0xa0000验证上位内存已经被系统占用。
如图23。
图23
12.自己设计一个查看内存的调试命令，验证上位内存的高地址端已经被系统占用。
如图24。
图24
NASM汇编器在将boot.asm生成为boot.bin的同时，会生成一个boot.lst列表文件，帮助开发者调试boot.asm文件中的汇编代码。
按照下面的步骤查看boot.lst文件：
1.在OSLab的“项目管理器”窗口中右键点击“boot”文件夹中的boot.asm文件。
2.在弹出的快捷菜单中选择“打开生成的列表文件”，在源代码编辑器中就会打开文件boot.lst。
3.将boot.lst文件和boot.asm文件对比可以发现，此文件包含了boot.asm文件中所有的汇编代码，同时在代码的左侧又添加了更多的信息。
如图25所示。
图25
4.在boot.lst中查找到软盘引导扇区程序第一条指令所在的行（第73行）如图26。
图26
7300000000EB6DjmpshortStart
此行包含的信息有：
●73是行号。
●00000000是此条指令相对于程序开始位置的偏移（第一条指令应该为0）。
●EB6D是此条指令的字节码，和之前记录下来的指令字节码是一致的。
软盘引导扇区程序的主要任务就是将软盘中的loader.bin文件加载到物理内存的0x1000处，然后跳转到loader程序的第一条指令（物理地址0x1000处的指令）继续执行loader程序。
按照下面的步骤调试上述过程：
1.在boot.lst文件中查找到加载完毕loader.bin文件后要跳转到loader程序中执行的指令（第278行）如图27。
图27
27800000181EA00100000jmp0:
LOADER_ORG
根据此指令相对于程序开始的偏移（0x0181）可以得到此指令的逻辑地址为0x0000:
7D81。
2.输入调试命令vb0x0000:
0x7d81添加一个断点。
3.输入调试命令c继续执行，到断点处中断。
在Console窗口中显示如图28。
图28
（0）[0x00007d81]0000:
7d81（unk.ctxt）:
jmpfar0000:
1000;ea00100000
此条指令就是跳转到物理内存0x1000处（即Loader程序的第一条指令）继续执行。
4.按照打开boot.lst文件的方法打开loader.lst文件，并在此文件中查找到loader程序的第一条指令（第33行）如图29。
3300000000E91801jmpStart
图29
5.输入调试命令xp/8b0x1000查看内存0x1000处的内存，验证此块内存的前三个字节和loader.lst文件中的第一条指令的字节码是相同的。
如图30。
图30
6.根据之前记录的loader.bin文件的大小，自己设计一个查看内存的调试命令，查看内存中loader程序结束位置的字节码，并与loader.lst文件中最后指令的字节码比较，验证loader程序被完全加载到了正确的位置。
2.4调试加载程序
Loader程序的主要任务是将操作系统内核（kernel.dll文件）加载到内存中，然后让CPU进入保护模式并且启用分页机制，最后进入操作系统内核开始执行（跳转到kernel.dll的入口点执行）。
按照下面的步骤调试上述过程：
1.在loader.lst文件中查找到准备进入EOS操作系统内核执行的指令（第755行）如图31。
7550000014FFF15[17010080]calldword[va_ImageEntry]
图31
2.计算此条指令的物理地址要复杂一些：
偏移地址实际上是相对于节（节SECTION是NASM汇编中的概念）开始的。
由于在boot.asm程序中只有一个节，所以之前计算的结果都是正确的，但是在loader.asm程序中有两个节，并且此条指令是在第二个节中。
下面引用的代码是loader.lst中第一个节的最后一条指令（第593行）如图32。
图32
593000003C1C20600ret6
根据第一个节中最后一条指令的偏移为0x03c1，并占用了3个字节（字节码C20600），可以计算出进入内核执行的指令所在的物理地址为0x1513（0x1000+0x03c1+0x3+0x14f）。
3.使用添加物理地址断点的调试命令pb0x1513添加一个断点。
4.输入调试命令c继续执行，到断点处中断。
在Console窗口中显示要执行的下一条指令：
（0）[0x00001513]0008:
0000000080001513（unk.ctxt）:
calldwordptrds:
0x80001117
;ff1517110080
注意，这里使用了函数指针的概念，所以，根据反汇编指令可以确定内核入口点函数的地址就保存在虚拟内存0x8000117处。
如图33。
图33
5.使用查看内存的调试命令x/1wx0x80001117查看内存中保存的32位函数入口地址，在Console窗口中输出，如图34。
0x0000000080001117:
0x800*****
图34
记录下Console输出的地址，后面的实验会验证内核入口点函数的地址与此地址是一致的。
2.5调试内核
调试内核的步骤如下：
1.在OSLab的“项目管理器”窗口中打开ke文件夹中的start.c文件，此文件中只定义了一个函数，就是操作系统内核的入口点函数KiSystemStartup。
2.在KiSystemStartup函数中的
KiInitializePic（）;
代码行（第61行）添加一个断点。
3.现在可以在Console窗口中输入调试命令c继续调试，在刚刚添加的断点处中断。
4.在start.c源代码文件中的KiSystemStartup函数名上点击鼠标右键，在弹出的快捷菜单中选择“添加监视”，KiSystemStartup函数就被添加到了“监视”窗口中。
在“监视”窗口中可以看到此函数的值为
{void（PVOID）}0x800*****如图36。
图36
与在虚拟内存x80001117处保存的函数入口地址相同，说明的确是由Loader程序进入了操作系统内核。
5.按F5继续执行EOS操作系统内核，在Display窗口中显示EOS操作系统已经启动，并且控制台程序已经开始运行了。
如图37。
图37
6.在OSLab中选择“调试”菜单中的“停止调试”，结束此次调试。
4、实验结果与分析
通过本次实验基本了解了EOS在PC机上从加电复位到成功启动的全过程，了解操作系统的启动过程。
EOS操作系统从软盘启动时要必须使用boot.bin和loader.bin两个程序。
删除一个是不能运行的。
升级会员 