操做系统ucore实验 lab1

最新推荐文章于 2019-11-11 07:44:22 发布

wa030

最新推荐文章于 2019-11-11 07:44:22 发布

阅读量508

点赞数

文章标签：操做系统 ucore

本文链接：https://blog.csdn.net/weixin_44418800/article/details/102915460

版权

本文档详细介绍了ucore操作系统实验的lab1，涉及计算机原理、Bootloader软件和ucore OS软件。实验包括理解Makefile生成执行文件的过程、使用QEMU执行并调试、分析bootloader进入保护模式和加载ELF格式OS的过程，以及实现函数调用堆栈跟踪和中断处理。通过一系列练习，读者将深入理解操作系统启动、内存管理和中断管理等核心概念。

摘要由CSDN通过智能技术生成

实验目的：

操作系统是一个软件，也需要通过某种机制加载并运行它。在这里我们将通过另外一个更加简单的软件-bootloader来完成这些工作。为此，我们需要完成一个能够切换到x86的保护模式并显示字符的bootloader，为启动操作系统ucore做准备。lab1提供了一个非常小的bootloader和ucore OS，整个bootloader执行代码小于512个字节，这样才能放到硬盘的主引导扇区中。通过分析和实现这个bootloader和ucore OS，读者可以了解到：

计算机原理

CPU的编址与寻址: 基于分段机制的内存管理
CPU的中断机制
外设：串口/并口/CGA，时钟，硬盘

Bootloader软件

编译运行bootloader的过程
调试bootloader的方法
PC启动bootloader的过程
ELF执行文件的格式和加载
外设访问：读硬盘，在CGA上显示字符串

ucore OS软件

编译运行ucore OS的过程
ucore OS的启动过程调试
ucore OS的方法
函数调用关系：在汇编级了解函数调用栈的结构和处理过程
中断管理：与软件相关的中断处理
外设管理：时钟

实验内容：

lab1中包含一个bootloader和一个OS。这个bootloader可以切换到X86保护模式，能够读磁盘并加载ELF执行文件格式，并显示字符。而这lab1中的OS只是一个可以处理时钟中断和显示字符的幼儿园级别OS。

练习

练习1：理解通过make生成执行文件的过程

在此练习中，大家需要通过静态分析代码来了解：

操作系统镜像文件ucore.img是如何一步一步生成的？(需要比较详细地解释Makefile中每一条相关命令和命令参数的含义，以及说明命令导致的结果)
一个被系统认为是符合规范的硬盘主引导扇区的特征是什么？

练习1.1

输入命令:

make V=

获得结果
在这里插入图片描述

从上面并没有看到：根据sign规范生成bootblock的命令
查看makefile文件找到：

@$(call totarget,sign) $(call outfile,bootblock)     
    $(bootblock)

所以从上面可以看出ucore.img的生成过程：

编译所有生成bin/kernel所需的文件
链接生成bin/kernel
编译bootasm.S bootmain.c sign.c
根据sign规范生成obj/bootblock.o
生成ucore.img

练习1.2

截取sign.c文件中的部分源码
在这里插入图片描述

主引导扇区的规则如下：

大小为512字节
多余的空间填0
第510个（倒数第二个）字节是0x55，
第511个（倒数第一个）字节是0xAA。

练习2：使用qemu执行并调试lab1中的软件

从CPU加电后执行的第一条指令开始，单步跟踪BIOS的执行。
在初始化位置0x7c00设置实地址断点,测试断点正常。
从0x7c00开始跟踪代码运行,将单步跟踪反汇编得到的代码与bootasm.S和 bootblock.asm进行比较。
自己找一个bootloader或内核中的代码位置，设置断点并进行测试。

练习2.1

tools/gdbinit的内容如下。可见，这里是对内核代码进行调试，并且将断点设置在内核代码的入口地址，即kern_init函数

file bin/kernel
target remote :1234
break kern_init
continue

为了从CPU加电后执行的第一条指令开始调试，需要修改tools/gdbinit的内容为：

set architecture i8086
file bin/bootblock
target remote :1234
break start
continue

执行make debug，这时会弹出一个QEMU窗口和一个Terminal窗口，这是正常的，因为我们在makefile中定义了debug的操作正是启动QEMU、启动Terminal并在其中运行gdb。

debug: $(UCOREIMG)
    $(V)$(QEMU) -S -s -parallel stdio -hda $< -serial null &
    $(V)sleep 2
    $(V)$(TERMINAL) -e "gdb -q -tui -x tools/gdbinit"

Terminal窗口此时停在0x0000fff0的位置，这是eip寄存器的值，而cs寄存器的值为0xf000. （遇到一个问题：此时无法正确反汇编出代码，使用x来查询内存0xfff0处的值时显示全0，不知道什么原因）

The target architecture is assumed to be i8086
0x0000fff0 in ?? ()
Breakpoint 1 at 0x7c00: file boot/bootasm.S, line 16.

输入si，执行1步，程序会跳转到0xe05b的地方。查看寄存器也可以发现eip的值变为0xe05b，而cs的值不变，仍然是0xf000.
反复输入si，以单步执行。（由于BIOS中全是汇编代码，看不懂其功能）。

练习2.2

我直接在tools/gdbinit中设置了断点break start，由于boot loader的入口为start，其地址为0x7c00，因此这和break *0x7c00效果是相同的。
设置断点后，输入continue或c，可以看到程序在0x7c00处停了下来，说明断点设置成功。

练习2.3

反汇编的代码与bootblock.asm基本相同，而与bootasm.S的差别在于：
（1）反汇编的代码中的指令不带指示长度的后缀，而bootasm.S的指令则有。比如，反汇编的代码是xor %eax, %eax，而bootasm.S的代码为xorw %ax, %ax
（2）反汇编的代码中的通用寄存器是32位（带有e前缀），而bootasm.S的代码中的通用寄存器是16位（不带e前缀）。

练习2.4

修改gdbinit文件，在0x7c4a处设置断点 (调用bootmain函数处)

set architecture i8086
target remote :1234
break *0x7c4a

输入 make debug ,得到结果：
在这里插入图片描述
断点设置正常

练习3：分析bootloader进入保护模式的过程

为何开启A20，以及如何开启A20
如何初始化GDT表
如何使能和进入保护模式

练习3.1

在i8086时代，CPU的数据总线是16bit，地址总线是20bit，寄存器是16bit，因此CPU只能访问1MB以内的空间。因为数据总线和寄存器只有16bit，如果需要获取20bit的数据, 我们需要做一些额外的操作，比如移位。实际上，CPU是通过对segment(每个segment大小恒定为64K) 进行移位后和offset一起组成了一个20bit的地址，这个地址就是实模式下访问内存的地址：