操作系统的启动实验报告Word下载.docx

操作系统的启动实验报告Word下载.docx

《操作系统的启动实验报告Word下载.docx》由会员分享，可在线阅读，更多相关《操作系统的启动实验报告Word下载.docx（14页珍藏版）》请在冰豆网上搜索。

指导教师

实验室名称地点

计算机基础第七实验室21B475

哈尔滨工程大学

一、实验概述

1.实验名称

2.实验目的

跟踪调试EOS在PC机上从加电复位到成功启动的全过程，了解操作系统的启动过程。

查看EOS启动后的状态和行为，理解操作系统启动后的工作方式。

3.实验类型

验证性实验

4.实验内容

调试EOS操作系统的启动过程包括：

（1）.使用Bochs做为远程目标机;

（2）.调试BIOS程序;

（3）.调试软盘引导扇区程序;

（4）.调试加载程序;

（5）.调试内核;

（6）.查看EOS启动后的状态和行为

二、实验环境

EOS操作系统和配套的IDE集成开发环境。

三、实验过程

1.设计思路和流程图

Kernel.dll开始执行，初始化EOS内核，EOS启动完毕

图2-1.EOS操作系统的启动过程流程图

2.算法实现：

验证性试验，无算法。

3.需要解决的问题及解答（试验指导）

（1）.为什么EOS操作系统从软盘启动时要使用boot.bin和loader.bin两个程序？

使用一个可以吗？

它们各自的主要功能是什么？

如果将loader.bin的功能移动到boot.bin文件中，则boot.bin文件的大小是否仍然能保持小于512字节？

答：

boot文件夹包含了两个汇编文件boot.asm和loader.asm。

这两个文件生成的二进制文件boot.bin和loader.bin会被写入软盘镜像文件。

操作系统启动时boot.bin和loader.bin引导软盘加载程序，二者缺一不可。

使用Boot.bin的主要功能是引导软盘；

loader.bin的主要功能是加载程序。

如果把loader.bin功能移动到boot.bin程序中，必然导致程序规模扩大，可能使其大于512字节。

（2）.软盘引导扇区加载完毕后内存中有两个用户可用的区域，为什么软盘引导扇区程序选择将loader.bin加载到第一个可用区域的0x1000处呢？

这样做有什么好处？

这样做会对loader.bin文件的大小有哪些限制。

首先用户只用两个可用区域，加载位置非此即彼。

第一个可用用户区是低地址区，且空间大小比较小，适合容纳小文件，所以我们选择将占用空间小的loder.bin加载到第一用户区。

优点：

由低地址开始，便于检索查找。

小文件占用小空间，节约资源。

限制：

loader.bin文件必须小于1c00k.

（3）.练习使用Bochs单步调试BIOS程序、软盘引导扇区程序和loader程序，加深对操作系统启动过程的理解。

（4）.仔细比较实验指导10-5图和图10-6，尝试说明哪个是应用程序的进程，它和系统进程有什么区别，哪个是应用程序的主线程，它和系统线程有什么区别。

图10-6是应用程序的进程，在进程列表中只有一个ID为1的系统进程，其优先级为24，包含有10个线程，其中的ID为2的线程是该进程的主线程，系统进程没有映像名称。

在线程列表中有10个线程，它们都是系统线程。

区别：

主线程的优先级别高。

存放在物理内存的低端。

4.主要数据结构、实现代码及其说明：

验证性实验，无此项目。

5.源程序并附上注释：

6.程序运行时的初值和运行结果,实验过程

1.调试BIOS程序

（1）.在Console窗口中输入调试命令sreg后按回车，显示当前CPU中各个段寄存器的值，如图2-1。

其中CS寄存器信息行中的“s=0xf000”表示CS寄存器的值为0xf000.

（2）.输入调试命令r后按回车，显示当前CPU中各个通用寄存器的值，如图10-3。

其中“rip:

0x00000000:

0000fff0”表示IP寄存器的值为0xfff0。

（3）.输入调试命令xp/1024b0x0000，查看开始的1024个字节的物理内存。

在Console中输出的这1K物理内存的值都为0，说明BIOS中断向量表还没有被加载到此处。

（4）.输入调试命令xp/512b0x7c00，查看软盘引导扇区应该被加载到的内存位置。

输出的内存值都为0，说明软盘引导扇区还没有被加载到此处。

2.调试软盘引导扇区程序

a.输入调试命令vb0x0000:

0x7c00，这样就在逻辑地址0x0000:

0x7c00（相当于物理地址0x7c00）处添加了一个断点。

b.输入调试命令c继续执行，在0x7c00处的断点中断。

中断后会在Console窗口中输出下一个要执行的指令，即软盘引导扇区程序的第一条指令，如下（0）[0x00007c00]0000:

7c00（unk.ctxt）:

jmp.+0x006d（0x00007c6f）;

eb6d

c.为了方便后面的使用，先在纸上分别记录下此条指令的字节码（eb6d）和此条指令要跳转执行的下一条指令的地址（括号中的0x00007c6f）。

d.输入调试命令sreg验证CS寄存器（0x0000）的值。

e.输入调试命令r验证IP寄存器（0x7c00）的值。

f.由于BIOS程序此时已经执行完毕，输入调试命令xp/1024b0x0000验证此时BIOS中断向量表已经被载入。

g.输入调试命令xp/512b0x7c00显示软盘引导扇区程序的所有字节码。

观察此块内存最开始的两个字节分别为0xeb和0x6d，这和引导程序第一条指令的字节码（eb6d）是相同的。

h.输入调试命令xp/512b0x0600验证图3-2中第一个用户可用区域是空白的。

i.输入调试命令xp/512b0x7e00验证图3-2中第二个用户可用区域是空白的。

j.自己设计两个查看内存的调试命令，分别验证这两个用户可用区域的高地址端也是空白的。

k.输入调试命令xp/512b0xa0000验证图3-2中上位内存已经被系统占用。

l.自己设计一个查看内存的调试命令，验证上位内存的高地址端已经被系统占用。

查看boot.lst文件

1）.在“项目管理器”窗口中，右键点击“boot”文件夹中的boot.asm文件。

2）.在弹出的快捷菜单中选择“打开生成的列表文件”，在源代码编辑器中就会打开文件boot.lst。

3）.将boot.lst文件和boot.asm文件对比可以发现，此文件包含了boot.asm文件中所有的汇编代码，同时在代码的左侧又添加了更多的信息。

4）.在boot.lst中查找到软盘引导扇区程序第一条指令所在的行（第73行）7300000000EB6DjmpshortStart此行包含的信息有：

●73是行号。

●00000000是此条指令相对于程序开始位置的偏移（第一条指令应该为0）。

●EB6D是此条指令的字节码，和之前记录下来的指令字节码是一致的。

软盘引导扇区程序的主要任务就是将软盘中的loader.bin文件加载到物理内存的0x1000处，然后跳转到loader程序的第一条指令（物理地址0x1000处的指令）继续执行loader程序。

按照下面的步骤调试此过程：

1）.在boot.lst文件中查找到加载完毕loader.bin文件后要跳转到loader程序中执行的指令（第278行）27800000181EA00100000jmp0:

LOADER_ORG根据此指令相对于程序开始（0x7C00）的偏移（0x0181）可以得到此指令的逻辑地址为0x0000:

7D81。

2）.输入调试命令vb0x0000:

0x7d81添加一个断点。

3）.输入调试命令c继续执行，到断点处中断。

在Console窗口中显示（0）[0x00007d81]0000:

7d81（unk.ctxt）:

jmpfar0000:

1000;

ea00100000此条指令会跳转到物理内存0x1000处（即Loader程序的第一条指令）继续执行。

4）.按照打开boot.lst文件的方法打开loader.lst文件，并在此文件中查找到loader程序的第一条指令（第33行）3300000000E91801jmpStart

5）.输入调试命令xp/8b0x1000查看内存0x1000处的数据，验证此块内存的前三个字节和loader.lst文件中的第一条指令的字节码是相同的。

6）.根据之前记录的loader.bin文件的大小，自己设计一个查看内存的调试命令，查看内存中loader程序结束位置的字节码，并与loader.lst文件中最后指令的字节码比较，验证loader程序被完全加载到了正确的位置。

调试加载程序

Loader程序的主要任务是将操作系统内核（kernel.dll文件）加载到内存中，然后让CPU进入保护模式并且启用分页机制，最后进入操作系统内核开始执行（跳转到kernel.dll的入口点执行）。

按照下面的步骤调试上述过程：

1.在loader.lst文件中查找到准备进入EOS操作系统内核执行的指令（第755行）7550000014FFF15[17010080]calldword[va_ImageEntry]

2.计算此条指令的物理地址要复杂一些：

偏移地址实际上是相对于节（节SECTION是NASM汇编中的概念）开始的。

由于在boot.asm程序中只有一个节，所以之前计算的结果都是正确的，但是在loader.asm程序中有两个节，并且此条指令是在第二个节中。

下面引用的代码是loader.lst中第一个节的最后一条指令（第593行）593000003C1C20600ret6因为第一个节中最后一条指令的偏移为0x03c1，并占用了3个字节（字节码为C20600），所以可以计算出进入内核执行的指令所在的物理地址为0x1513（0x1000+0x03c1+0x3+0x14f）。

3.使用添加物理地址断点的调试命令pb0x1513添加一个断点。

4.输入调试命令c继续执行，到断点处中断。

在Console窗口中显示要执行的下一条指令（注意，此时的逻辑地址都为虚拟地址）：

（0）[0x00001513]0008:

0000000080001513（unk.ctxt）:

calldwordptrds:

0x80001117;

ff1517110080由于这里使用了函数指针的概念，所以，根据反汇编指令可以确定内核入口点函数的地址就保存在虚拟地址0x8000117处的四个字节中。

5.使用查看虚拟内存的调试命令x/1wx0x80001117查看内存中保存的32位函数入口地址，在Console窗口中会输出类似下面的内容：

0x0000000080001117<

bogus+0>

:

0x800*****记录下此块内存中保存的函数地址，后面的实验会验证内核入口点函数的地址与此地址是一致的。

调试内核：

1）.在OSLab的“项目管理器”窗口中打开ke文件夹中的start.c文件，此文件中只定义了一个函数，就是操作系统内核的入口点函数KiSystemStartup。

2）.在KiSystemStartup函数中的代码行（第61行）KiInitializePic（）;

添加一个断点。

3）.现在可以在Console窗口中输入调试命令c继续调试，在刚刚添加的断点处中断。

4）.在start.c源代码文