ucore lab1实验笔记-白红宇

ucore lab1实验笔记

阅读量：5279 次

发布时间：2019-06-14

本文共 13577 字，大约阅读时间需要 45 分钟。

实验目的：

操作系统是一个软件，也需要通过某种机制加载并运行它。在这里我们将通过另外一个更加简单的软件-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的方法
- 函数调用关系：在汇编级了解函数调用栈的结构和处理过程
- 中断管理：与软件相关的中断处理
- 外设管理：时钟

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

操作系统镜像文件ucore.img是如何一步一步生成的？

一个被系统认为是符合规范的硬盘主引导扇区的特征是什么？

当执行make时，一般只会显示输出，不会显示make到底执行了哪些命令。

如想了解make执行了哪些命令，可以执行：

$ make "V="

要获取更多有关make的信息，可上网查询，并请执行

$ man make

阅读Makefile：

$ less Makefile

主引导扇区的特征，看这里的代码：

$ less tools/sign.c

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

从CPU加电后执行的第一条指令开始，单步跟踪BIOS的执行。

在初始化位置0x7c00设置实地址断点，测试断点正常。

从0x7c00开始跟踪代码运行,将单步跟踪反汇编得到的代码与bootasm.S和 bootblock.asm进行比较。

找一个bootloader或内核中的代码位置，设置断点并进行测试。

查看 labcodes_answer/lab1_result/tools/lab1init 文件，用如下命令调试bootloader第一条指令：

$ cd labcodes_answer/lab1_result/$ make lab1-mon

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

BIOS将通过读取硬盘主引导扇区到内存，并转跳到对应内存中的位置执行bootloader。分析bootloader是如何完成从实模式进入保护模式的。

阅读小节“保护模式和分段机制”和lab1/boot/bootasm.S源码，了解如何从实模式切换到保护模式，需要了解：

为何开启A20，以及如何开启A20

如何初始化GDT表

如何使能和进入保护模式

练习4：分析bootloader加载ELF格式的OS的过程。

阅读bootmain.c，了解bootloader如何加载ELF文件。分析源代码和通过qemu来运行并调试bootloader&OS，

bootloader如何读取硬盘扇区的？

bootloader是如何加载ELF格式的OS？

阅读“硬盘访问概述”，“ELF执行文件格式概述”这两小节。

练习5：实现函数调用堆栈跟踪函数

在lab1中完成kdebug.c中函数print_stackframe的实现，可以通过函数print_stackframe来跟踪函数调用堆栈中记录的返回地址。在如果能够正确实现此函数，可在lab1中执行 “make qemu”后，在qemu模拟器中得到类似如下的输出：

1 …… 2 ebp:0x00007b28 eip:0x00100992 args:0x00010094 0x00010094 0x00007b58 0x00100096 3     kern/debug/kdebug.c:305: print_stackframe+22 4 ebp:0x00007b38 eip:0x00100c79 args:0x00000000 0x00000000 0x00000000 0x00007ba8 5     kern/debug/kmonitor.c:125: mon_backtrace+10 6 ebp:0x00007b58 eip:0x00100096 args:0x00000000 0x00007b80 0xffff0000 0x00007b84 7     kern/init/init.c:48: grade_backtrace2+33 8 ebp:0x00007b78 eip:0x001000bf args:0x00000000 0xffff0000 0x00007ba4 0x00000029 9     kern/init/init.c:53: grade_backtrace1+3810 ebp:0x00007b98 eip:0x001000dd args:0x00000000 0x00100000 0xffff0000 0x0000001d11     kern/init/init.c:58: grade_backtrace0+2312 ebp:0x00007bb8 eip:0x00100102 args:0x0010353c 0x00103520 0x00001308 0x0000000013     kern/init/init.c:63: grade_backtrace+3414 ebp:0x00007be8 eip:0x00100059 args:0x00000000 0x00000000 0x00000000 0x00007c5315     kern/init/init.c:28: kern_init+8816 ebp:0x00007bf8 eip:0x00007d73 args:0xc031fcfa 0xc08ed88e 0x64e4d08e 0xfa7502a817 
      
       : -- 0x00007d72 –18 ……

阅读小节“函数堆栈”，了解编译器如何建立函数调用关系的。在完成lab1编译后，查看lab1/obj/bootblock.asm，了解bootloader源码与机器码的语句和地址等的对应关系；查看lab1/obj/kernel.asm，了解ucore OS源码与机器码的语句和地址等的对应关系。

要求完成函数kern/debug/kdebug.c::print_stackframe的实现，提交改进后源代码包（可以编译执行）。

由于显示完整的栈结构需要解析内核文件中的调试符号，较为复杂和繁琐。代码中有一些辅助函数可以使用。例如可以通过调用print_debuginfo函数完成查找对应函数名并打印至屏幕的功能。具体可以参见kdebug.c代码中的注释。

练习6：完善中断初始化和处理

除了系统调用中断(T_SYSCALL)使用陷阱门描述符且权限为用户态权限以外，其它中断均使用特权级(DPL)为０的中断门描述符，权限为内核态权限；而ucore的应用程序处于特权级３，需要采用｀int 0x80`指令操作（这种方式称为软中断，软件中断，Tra中断，在lab5会碰到）来发出系统调用请求，并要能实现从特权级３到特权级０的转换，所以系统调用中断(T_SYSCALL)所对应的中断门描述符中的特权级（DPL）需要设置为３。

阅读小节“中断与异常”。

项目组成

lab1的整体目录结构如下所示：

.├── boot│   ├── asm.h│   ├── bootasm.S│   └── bootmain.c├── kern│   ├── debug│   │   ├── assert.h│   │   ├── kdebug.c│   │   ├── kdebug.h│   │   ├── kmonitor.c│   │   ├── kmonitor.h│   │   ├── panic.c│   │   └── stab.h│   ├── driver│   │   ├── clock.c│   │   ├── clock.h│   │   ├── console.c│   │   ├── console.h│   │   ├── intr.c│   │   ├── intr.h│   │   ├── kbdreg.h│   │   ├── picirq.c│   │   └── picirq.h│   ├── init│   │   └── init.c│   ├── libs│   │   ├── readline.c│   │   └── stdio.c│   ├── mm│   │   ├── memlayout.h│   │   ├── mmu.h│   │   ├── pmm.c│   │   └── pmm.h│   └── trap│       ├── trap.c│       ├── trapentry.S│       ├── trap.h│       └── vectors.S├── libs│   ├── defs.h│   ├── elf.h│   ├── error.h│   ├── printfmt.c│   ├── stdarg.h│   ├── stdio.h│   ├── string.c│   ├── string.h│   └── x86.h├── Makefile└── tools    ├── function.mk    ├── gdbinit    ├── grade.sh    ├── kernel.ld    ├── sign.c    └── vector.c10 directories, 48 files

其中一些比较重要的文件说明如下：

bootloader部分

boot/bootasm.S ：定义并实现了bootloader最先执行的函数start，此函数进行了一定的初始化，完成了从实模式到保护模式的转换，并调用bootmain.c中的bootmain函数。

boot/bootmain.c：定义并实现了bootmain函数实现了通过屏幕、串口和并口显示字符串。bootmain函数加载ucore操作系统到内存，然后跳转到ucore的入口处执行。

boot/asm.h：是bootasm.S汇编文件所需要的头文件，主要是一些与X86保护模式的段访问方式相关的宏定义。

ucore操作系统部分

系统初始化部分：

kern/init/init.c：ucore操作系统的初始化启动代码

内存管理部分：

kern/mm/memlayout.h：ucore操作系统有关段管理（段描述符编号、段号等）的一些宏定义

kern/mm/mmu.h：ucore操作系统有关X86 MMU等硬件相关的定义，包括EFLAGS寄存器中各位的含义，应用/系统段类型，中断门描述符定义，段描述符定义，任务状态段定义，NULL段声明的宏SEG_NULL, 特定段声明的宏SEG，设置中断门描述符的宏SETGATE（在练习6中会用到）

kern/mm/pmm.[ch]：设定了ucore操作系统在段机制中要用到的全局变量：任务状态段ts，全局描述符表 gdt[]，加载全局描述符表寄存器的函数lgdt，临时的内核栈stack0；以及对全局描述符表和任务状态段的初始化函数gdt_init

外设驱动部分：

kern/driver/intr.[ch]：实现了通过设置CPU的eflags来屏蔽和使能中断的函数；

kern/driver/picirq.[ch]：实现了对中断控制器8259A的初始化和使能操作；

kern/driver/clock.[ch]：实现了对时钟控制器8253的初始化操作；- kern/driver/console.[ch]：实现了对串口和键盘的中断方式的处理操作；

中断处理部分：

kern/trap/vectors.S：包括256个中断服务例程的入口地址和第一步初步处理实现。注意，此文件是由tools/vector.c在编译ucore期间动态生成的；

kern/trap/trapentry.S：紧接着第一步初步处理后，进一步完成第二步初步处理；并且有恢复中断上下文的处理，即中断处理完毕后的返回准备工作；

kern/trap/trap.[ch]：紧接着第二步初步处理后，继续完成具体的各种中断处理操作；

内核调试部分：

kern/debug/kdebug.[ch]：提供源码和二进制对应关系的查询功能，用于显示调用栈关系。其中补全print_stackframe函数是需要完成的练习。其他实现部分不必深究。

kern/debug/kmonitor.[ch]：实现提供动态分析命令的kernel monitor，便于在ucore出现bug或问题后，能够进入kernel monitor中，查看当前调用关系。实现部分不必深究。

kern/debug/panic.c | assert.h：提供了panic函数和assert宏，便于在发现错误后，调用kernel monitor。大家可在编程实验中充分利用assert宏和panic函数，提高查找错误的效率。

公共库部分

libs/defs.h：包含一些无符号整型的缩写定义。

Libs/x86.h：一些用GNU C嵌入式汇编实现的C函数（由于使用了inline关键字，所以可以理解为宏）。

工具部分

Makefile和function.mk：指导make完成整个软件项目的编译，清除等工作。

sign.c：一个C语言小程序，是辅助工具，用于生成一个符合规范的硬盘主引导扇区。

tools/vector.c：生成vectors.S，此文件包含了中断向量处理的统一实现。

编译方法

首先下载lab1.tar.bz2，然后解压lab1.tar.bz2。在lab1目录下执行make，可以生成ucore.img（生成于bin目录下）。ucore.img是一个包含了bootloader或OS的硬盘镜像，通过执行如下命令可在硬件虚拟环境 qemu中运行bootloader或OS：

$ make qemu

则可以得到如下显示界面（仅供参考）

(THU.CST) os is loading ...Special kernel symbols:  entry  0x00100000 (phys)  etext  0x00103468 (phys)  edata  0x0010ea18 (phys)  end    0x0010fd80 (phys)Kernel executable memory footprint: 64KBebp:0x00007b38 eip:0x00100a55 args:0x00010094 0x00010094 0x00007b68 0x00100084     kern/debug/kdebug.c:305: print_stackframe+21ebp:0x00007b48 eip:0x00100d3a args:0x00000000 0x00000000 0x00000000 0x00007bb8     kern/debug/kmonitor.c:125: mon_backtrace+10ebp:0x00007b68 eip:0x00100084 args:0x00000000 0x00007b90 0xffff0000 0x00007b94     kern/init/init.c:48: grade_backtrace2+19ebp:0x00007b88 eip:0x001000a5 args:0x00000000 0xffff0000 0x00007bb4 0x00000029     kern/init/init.c:53: grade_backtrace1+27ebp:0x00007ba8 eip:0x001000c1 args:0x00000000 0x00100000 0xffff0000 0x00100043     kern/init/init.c:58: grade_backtrace0+19ebp:0x00007bc8 eip:0x001000e1 args:0x00000000 0x00000000 0x00000000 0x00103480     kern/init/init.c:63: grade_backtrace+26ebp:0x00007be8 eip:0x00100050 args:0x00000000 0x00000000 0x00000000 0x00007c4f     kern/init/init.c:28: kern_init+79ebp:0x00007bf8 eip:0x00007d61 args:0xc031fcfa 0xc08ed88e 0x64e4d08e 0xfa7502a8     
      
       : -- 0x00007d60 --++ setup timer interrupts0: @ring 00:  cs = 80:  ds = 100:  es = 100:  ss = 10+++ switch to  user  mode +++1: @ring 31:  cs = 1b1:  ds = 231:  es = 231:  ss = 23+++ switch to kernel mode +++2: @ring 02:  cs = 82:  ds = 102:  es = 102:  ss = 10100 ticks100 ticks100 ticks100 ticks

BIOS启动过程

当计算机加电后，一般不直接执行操作系统，而是执行系统初始化软件完成基本IO初始化和引导加载功能。简单地说，系统初始化软件就是在操作系统内核运行之前运行的一段小软件。通过这段小软件，我们可以初始化硬件设备、建立系统的内存空间映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境。最终引导加载程序把操作系统内核映像加载到RAM中，并将系统控制权传递给它。

对于绝大多数计算机系统而言，操作系统和应用软件是存放在磁盘（硬盘/软盘）、光盘、EPROM、ROM、Flash等可在掉电后继续保存数据的存储介质上。计算机启动后，CPU一开始会到一个特定的地址开始执行指令，这个特定的地址存放了系统初始化软件，负责完成计算机基本的IO初始化，这是系统加电后运行的第一段软件代码。对于Intel 80386的体系结构而言，PC机中的系统初始化软件由BIOS (Basic Input Output System，即基本输入/输出系统，其本质是一个固化在主板Flash/CMOS上的软件)和位于软盘/硬盘引导扇区中的OS Boot Loader（在ucore中的bootasm.S和bootmain.c）一起组成。BIOS实际上是被固化在计算机ROM（只读存储器）芯片上的一个特殊的软件，为上层软件提供最底层的、最直接的硬件控制与支持。更形象地说，BIOS就是PC计算机硬件与上层软件程序之间的一个"桥梁"，负责访问和控制硬件。

以Intel 80386为例，计算机加电后，CPU从物理地址0xFFFFFFF0（由初始化的CS：EIP确定，此时CS和IP的值分别是0xF000和0xFFF0)）开始执行。在0xFFFFFFF0这里只是存放了一条跳转指令，通过跳转指令跳到BIOS例行程序起始点。BIOS做完计算机硬件自检和初始化后，会选择一个启动设备（例如软盘、硬盘、光盘等），并且读取该设备的第一扇区(即主引导扇区或启动扇区)到内存一个特定的地址0x7c00处，然后CPU控制权会转移到那个地址继续执行。至此BIOS的初始化工作做完了，进一步的工作交给了ucore的bootloader。

[补充信息]

Intel的CPU具有很好的向后兼容性。在16位的8086 CPU时代，内存限制在1MB范围内，且BIOS的代码固化在EPROM中。在基于Intel的8086 CPU的PC机中的EPROM被编址在1ＭB内存地址空间的最高64KB中。PC加电后，CS寄存器初始化为0xF000，IP寄存器初始化为0xFFF0，所以CPU要执行的第一条指令的地址为CS:IP=0xF000:0XFFF0（Segment:Offset 表示）=0xFFFF0（Linear表示）。这个地址位于被固化EPROM中，指令是一个长跳转指令JMP F000:E05B。这样就开启了BIOS的执行过程。

到了32位的80386 CPU时代，内存空间扩大到了4G，多了段机制和页机制，但Intel依然很好地保证了80386向后兼容8086。地址空间的变化导致无法直接采用8086的启动约定。如果把BIOS启动固件编址在0xF000起始的64KB内存地址空间内，就会把整个物理内存地址空间隔离成不连续的两段，一段是0xF000以前的地址，一段是1MB以后的地址，这很不协调。为此，intel采用了一个折中的方案：默认将执行BIOS ROM编址在32位内存地址空间的最高端，即位于4GB地址的最后一个64KB内。在PC系统开机复位时，CPU进入实模式，并将CS寄存器设置成0xF000，将它的shadow register的Base值初始化设置为0xFFFF0000，EIP寄存器初始化设置为0x0000FFF0。所以机器执行的第一条指令的物理地址是0xFFFFFFF0。80386的BIOS代码也要和以前8086的BIOS代码兼容，故地址0xFFFFFFF0处的指令还是一条长跳转指令`jmp F000:E05B`。注意，这个长跳转指令会触发更新CS寄存器和它的shadow register，即执行`jmp F000 : E05B`后，CS将被更新成0xF000。表面上看CS其实没有变化，但CS的shadow register被更新为另外一个值了，它的Base域被更新成0x000F0000，此时形成的物理地址为Base+EIP=0x000FE05B，这就是CPU执行的第二条指令的地址。此时这条指令的地址已经是1M以内了，且此地址不再位于BIOS ROM中，而是位于RAM空间中。由于Intel设计了一种映射机制，将内存高端的BIOS ROM映射到1MB以内的RAM空间里，并且可以使这一段被映射的RAM空间具有与ROM类似的只读属性。所以PC机启动时将开启这种映射机制，让4GB地址空间的最高一个64KB的内容等同于1MB地址空间的最高一个64K的内容，从而使得执行了长跳转指令后，其实是回到了早期的8086 CPU初始化控制流，保证了向下兼容。

bootloader启动过程

BIOS将通过读取硬盘主引导扇区到内存，并转跳到对应内存中的位置执行bootloader。bootloader完成的工作包括：

切换到保护模式，启用分段机制

读磁盘中ELF执行文件格式的ucore操作系统到内存

显示字符串信息

把控制权交给ucore操作系统

对应其工作的实现文件在lab1中的boot目录下的三个文件asm.h、bootasm.S和bootmain.c。

地址空间

分段机制涉及5个关键内容：逻辑地址（Logical Address,应用程序员看到的地址，在操作系统原理上称为虚拟地址，以后提到虚拟地址就是指逻辑地址）、物理地址（Physical Address, 实际的物理内存地址）、段描述符表（包含多个段描述符的“数组”）、段描述符（描述段的属性，及段描述符表这个“数组”中的“数组元素”）、段选择子（即段寄存器中的值，用于定位段描述符表中段描述符表项的索引）

(1) 逻辑地址空间从应用程序的角度看，逻辑地址空间就是应用程序员编程所用到的地址空间，比如下面的程序片段： int val=100; int * point=&val;

其中指针变量point中存储的即是一个逻辑地址。在基于80386的计算机系统中，逻辑地址有一个16位的段寄存器（也称段选择子，段选择子）和一个32位的偏移量构成。

(2) 物理地址空间从操作系统的角度看，CPU、内存硬件（通常说的“内存条”）和各种外设是它主要管理的硬件资源而内存硬件和外设分布在物理地址空间中。物理地址空间就是一个“大数组”，CPU通过索引（物理地址）来访问这个“大数组”中的内容。物理地址是指CPU提交到内存总线上用于访问计算机内存和外设的最终地址。

物理地址空间的大小取决于CPU实现的物理地址位数，在基于80386的计算机系统中，CPU的物理地址空间为4GB，如果计算机系统实际上有1GB物理内存（即我们通常说的内存条），而其他硬件设备的IO寄存器映射到起始物理地址为3GB的256MB大小的地址空间，则该计算机系统的物理地址空间如下所示：

+------------------+  <- 0xFFFFFFFF (4GB)|     无效空间      ||                  |+------------------+  <- addr:3G+256M|     256MB        ||   IO外设地址空间   ||                  |+------------------+  <- 0xC0000000(3GB)|                  |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\|     无效空间      |+------------------+  <- 0x40000000(1GB)|                  ||    实际有效内存    ||                  |+------------------+  <- 0x00100000 (1MB)|     BIOS ROM     |+------------------+  <- 0x000F0000 (960KB)|  16-bit devices, ||  expansion ROMs  |+------------------+  <- 0x000C0000 (768KB)|   VGA Display    |+------------------+  <- 0x000A0000 (640KB)|                  ||    Low Memory    ||                  |+------------------+  <- 0x00000000

(3) 线性地址空间

一台计算机只有一个物理地址空间，但在操作系统的管理下，每个程序都认为自己独占整个计算机的物理地址空间。为了让多个程序能够有效地相互隔离和使用物理地址空间，引入线性地址空间（也称虚拟地址空间）的概念。线性地址空间的大小取决于CPU实现的线性地址位数，在基于80386的计算机系统中，CPU的线性地址空间为4GB。线性地址空间会被映射到某一部分或整个物理地址空间，并通过索引（线性地址）来访问其中的内容。线性地址又称虚拟地址，是进行逻辑地址转换后形成的地址索引，用于寻址线性地址空间。但CPU未启动分页机制时，线性地址等于物理地址；当CPU启动分页机制时，线性地址还需经过分页地址转换形成物理地址后，CPU才能访问内存硬件和外设。三种地址的关系如下所示：

启动分段机制，未启动分页机制：逻辑地址--> (分段地址转换) -->线性地址==物理地址

启动分段和分页机制：逻辑地址--> (分段地址转换) -->线性地址-->分页地址转换) -->物理地址

在操作系统的管理下，采用灵活的内存管理机制，在只有一个物理地址空间的情况下，可以存在多个线性地址空间。

ELF文件格式概述

ELF(Executable and linking format)文件格式是Linux系统下的一种常用目标文件(object file)格式，有三种主要类型:

用于执行的可执行文件(executable file)，用于提供程序的进程映像，加载的内存执行。这也是本实验的OS文件类型。

用于连接的可重定位文件(relocatable file)，可与其它目标文件一起创建可执行文件和共享目标文件。

共享目标文件(shared object file),连接器可将它与其它可重定位文件和共享目标文件连接成其它的目标文件，动态连接器又可将它与可执行文件和其它共享目标文件结合起来创建一个进程映像。

这里只分析与本实验相关的ELF可执行文件类型。ELF header在文件开始处描述了整个文件的组织。ELF的文件头包含整个执行文件的控制结构，其定义在elf.h中：

1 struct elfhdr { 2   uint magic;  // must equal ELF_MAGIC 3   uchar elf[12]; 4   ushort type; 5   ushort machine; 6   uint version; 7   uint entry;  // 程序入口的虚拟地址 8   uint phoff;  // program header 表的位置偏移 9   uint shoff;10   uint flags;11   ushort ehsize;12   ushort phentsize;13   ushort phnum; //program header表中的入口数目14   ushort shentsize;15   ushort shnum;16   ushort shstrndx;17 };

program header描述与程序执行直接相关的目标文件结构信息，用来在文件中定位各个段的映像，同时包含其他一些用来为程序创建进程映像所必需的信息。可执行文件的程序头部是一个program header结构的数组，每个结构描述了一个段或者系统准备程序执行所必需的其它信息。目标文件的 “段” 包含一个或者多个 “节区”（section），也就是“段内容（Segment Contents）” 。程序头部仅对于可执行文件和共享目标文件有意义。可执行目标文件在ELF头部的e_phentsize和e_phnum成员中给出其自身程序头部的大小。程序头部的数据结构如下表所示：

1 struct proghdr { 2   uint type;   // 段类型 3   uint offset;  // 段相对文件头的偏移值 4   uint va;     // 段的第一个字节将被放到内存中的虚拟地址 5   uint pa; 6   uint filesz; 7   uint memsz;  // 段在内存映像中占用的字节数 8   uint flags; 9   uint align;10 };

根据elfhdr和proghdr的结构描述，bootloader就可以完成对ELF格式的ucore操作系统的加载过程（参见boot/bootmain.c中的bootmain函数）。

[补充材料]

Link addr& Load addr

Link Address是指编译器指定代码和数据所需要放置的内存地址，由链接器配置。Load Address是指程序被实际加载到内存的位置（由程序加载器ld配置）。一般由可执行文件结构信息和加载器可保证这两个地址相同。Link Addr和LoadAddr不同会导致：

直接跳转位置错误

直接内存访问(只读数据区或bss等直接地址访问)错误

堆和栈等的使用不受影响，但是可能会覆盖程序、数据区域注意：也存在Link地址和Load地址不一样的情况（例如：动态链接库）。

操作系统启动过程

当bootloader通过读取硬盘扇区把ucore在系统加载到内存后，就转跳到ucore操作系统在内存中的入口位置（kern/init.c中的kern_init函数的起始地址），这样ucore就接管了整个控制权。当前的ucore功能很简单，只完成基本的内存管理和外设中断管理。ucore主要完成的工作包括：