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

上传人:b****6 文档编号:2774419 上传时间:2022-11-15 格式:DOCX 页数:14 大小:1.45MB
下载 相关 举报
操作系统的启动实验报告.docx_第1页
第1页 / 共14页
操作系统的启动实验报告.docx_第2页
第2页 / 共14页
操作系统的启动实验报告.docx_第3页
第3页 / 共14页
操作系统的启动实验报告.docx_第4页
第4页 / 共14页
操作系统的启动实验报告.docx_第5页
第5页 / 共14页
点击查看更多>>
下载资源
资源描述

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

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

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

操作系统的启动实验报告

操作系统

实验报告

课程名称

操作系统实验

实验项目名称

操作系统的启动

学号

班级

20100612

姓名

专业

计算机科学与技术

学生所在学院

计算机科学与技术学院

指导教师

实验室名称地点

计算机基础第七实验室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:

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

调试内核:

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

2).在KiSystemStartup函数中的代码行(第61行)KiInitializePic();添加一个断点。

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

4).在start.c源代码文

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 工作范文 > 行政公文

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1