操作系统是一种需要通过某种机制加载和操作的软件。在这里，我们将使用另一个更简单的软件-bootloader完成这些工作。为此，我们需要完成一个切换x显示字符的86保护模式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.操作系统镜像文件ucore.img它是如何一步一步成的？(需要详细解释Makefile每个相关命令和命令参数的含义，以及命令的结果)
2.硬盘主导风扇区域的特点是什么，被系统视为标准？

补充材料：
如何调试Makefile
当执行make输出一般只显示，不显示make执行了哪些命令？
如想了解make可以执行哪些命令：
$ make "V="
获得更多相关信息make信息可以在网上查询，请执行
$ man make

首先在lab打开终端运行目录make V，相当于设置一个标记make可以显示详细的编译执行过程：

yeyuhl@ubuntu:~/code/os_kernel_lab-master/ucore_os_lab/labcodes/lab1$ make V=   cc kern/init/init.c gcc -Ikern/init/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/init/init.c -o obj/kern/init/init.o kern/init/init.c:95:1: warning: ‘lab1_switch_test’ defined but not used [-Wunused-function]    95 | lab1_switch_test(void) {       | ^~~~~~~~~~~~~~~~   cc kern/libs/stdio.c gcc -Ikern/libs/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/libs/stdio.c -o obj/kern/libs/stdio.o   cc kern/libs/readline.c gcc -Ikern/libs/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/libs/readline.c -o obj/kern/libs/readline.o   cc kern/debug/panic.c gcc -Ikern/debug/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/debug/panic.c -o obj/kern/debug/panic.o kern/debug/panic.c: In function ‘__panic’: kern/debug/panic.c:27:5: warning: implicit declaration of function ‘print_stackframe’; did you mean ‘print_trapframe’? [-Wimplicit-function-declaration]    27 |     print_stackframe();       |     ^~~~~~~~~~~~~~~~       |     print_trapframe   cc kern/debug/kdebug.c gcc -Ikern/debug/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/debug/kdebug.c -o obj/kern/debug/kdebug.o kern/debug/kdebug.c:251:1: warning: ‘read_eip’ defined but not used [-Wunused-function]   251 | read_eip(void) {       | ^~~~~~~~   cc kern/debug/kmonitor.c gcc -Ikern/debug/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/debug/kmonitor.c -o obj/kern/debug/kmonitor.o   cc kern/driver/clock.c gcc -Ikern/driver/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/driver/clock.c -o obj/kern/driver/clock.o   cc kern/driver/console.c gcc -Ikern/driver/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/driver/console.c -o obj/kern/driver/console.o   cc kern/driver/picirq.c gcc -Ikern/driver/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/driver/picirq.c -o obj/kern/driver/picirq.o   cc kern/driver/intr.c gcc -Ikern/driver/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/driver/intr.c -o obj/kern/driver/intr.o   cc kern/trap/trap.c gcc -Ikern/trap/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Iern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/trap/trap.c -o obj/kern/trap/trap.o
kern/trap/trap.c: In function ‘print_trapframe’:
kern/trap/trap.c:100:16: warning: taking address of packed member of ‘struct trapframe’ may result in an unaligned pointer value [-Waddress-of-packed-member]
  100 |     print_regs(&tf->tf_regs);
      |                ^~~~~~~~~~~~
At top level:
kern/trap/trap.c:30:26: warning: ‘idt_pd’ defined but not used [-Wunused-variable]
   30 | static struct pseudodesc idt_pd = {
      |                          ^~~~~~
kern/trap/trap.c:14:13: warning: ‘print_ticks’ defined but not used [-Wunused-function]
   14 | static void print_ticks() {
      |             ^~~~~~~~~~~
+ cc kern/trap/vectors.S
gcc -Ikern/trap/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/trap/vectors.S -o obj/kern/trap/vectors.o
+ cc kern/trap/trapentry.S
gcc -Ikern/trap/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/trap/trapentry.S -o obj/kern/trap/trapentry.o
+ cc kern/mm/pmm.c
gcc -Ikern/mm/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/mm/pmm.c -o obj/kern/mm/pmm.o
+ cc libs/string.c
gcc -Ilibs/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/  -c libs/string.c -o obj/libs/string.o
+ cc libs/printfmt.c
gcc -Ilibs/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/  -c libs/printfmt.c -o obj/libs/printfmt.o
+ ld bin/kernel
ld -m    elf_i386 -nostdlib -T tools/kernel.ld -o bin/kernel  obj/kern/init/init.o obj/kern/libs/stdio.o obj/kern/libs/readline.o obj/kern/debug/panic.o obj/kern/debug/kdebug.o obj/kern/debug/kmonitor.o obj/kern/driver/clock.o obj/kern/driver/console.o obj/kern/driver/picirq.o obj/kern/driver/intr.o obj/kern/trap/trap.o obj/kern/trap/vectors.o obj/kern/trap/trapentry.o obj/kern/mm/pmm.o  obj/libs/string.o obj/libs/printfmt.o
+ cc boot/bootasm.S
gcc -Iboot/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Os -nostdinc -c boot/bootasm.S -o obj/boot/bootasm.o
+ cc boot/bootmain.c
gcc -Iboot/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Os -nostdinc -c boot/bootmain.c -o obj/boot/bootmain.o
+ cc tools/sign.c
gcc -Itools/ -g -Wall -O2 -c tools/sign.c -o obj/sign/tools/sign.o
gcc -g -Wall -O2 obj/sign/tools/sign.o -o bin/sign
+ ld bin/bootblock
ld -m    elf_i386 -nostdlib -N -e start -Ttext 0x7C00 obj/boot/bootasm.o obj/boot/bootmain.o -o obj/bootblock.o
'obj/bootblock.out' size: 496 bytes
build 512 bytes boot sector: 'bin/bootblock' success!
dd if=/dev/zero of=bin/ucore.img count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB, 4.9 MiB) copied, 0.0117931 s, 434 MB/s
dd if=bin/bootblock of=bin/ucore.img conv=notrunc
1+0 records in
1+0 records out
512 bytes copied, 0.000108956 s, 4.7 MB/s
dd if=bin/kernel of=bin/ucore.img seek=1 conv=notrunc
154+1 records in
154+1 records out
78916 bytes (79 kB, 77 KiB) copied, 0.000387761 s, 204 MB/s

根据以上编译过程，我们可以把ucore.img生成分成以下几个步骤：

(1)调用GCC将部分.c和.S文件，编译成了目标文件。
kern/init目录：init.c（系统初始化部分）
kern/libs目录：stdio.c、readline.c（公共库部分）
kern/debug目录：panic.c、kdebug.c、kmonitor.c（内核调试部分）
kern/driver目录：clock.c、console.c、picirq.c、intr.c（外设驱动部分）
kern/trap目录：trap.c、vectors.S、trapentry.S（中断处理部分）
kern/mm目录：pmm.c（内存管理部分）
libs目录：string.c、printfmt.c（公共库部分）
即代码+ cc kern/init/init.c以下到+ ld bin/kernel以上的过程。
我们截取一个文件的编译过程来讲述相关命令和命令参数的含义，以及说明命令导致的结果：

+ cc kern/libs/readline.c
gcc -Ikern/libs/ -march=i686 -fno-builtin -fno-PIC -Wall -ggdb -m32 -gstabs -nostdinc  -fno-stack-protector -Ilibs/ -Ikern/debug/ -Ikern/driver/ -Ikern/trap/ -Ikern/mm/ -c kern/libs/readline.c -o obj/kern/libs/readline.o

关键参数：
-march=i686：编译生成的目标文件指令集架构为i686，即Intel 32位指令集。
-fno-builtin：只识别以_builtin_作为前缀的内建函数，并可对其进行优化，并且防止内核代码函数名与内建函数名冲突而被优化的问题（内建函数就是编译器内部使用的函数）。
-fno-PIC：PIC（position independent code），使用绝对位置，而不是相对位置。
-Wall：显示所有编译警告。
-ggdb：尽可能的生成 gdb 的可以使用的调试信息。
-m32：生成32位目标文件。
-gstabs：以 stabs 格式声称调试信息，但是不包括 gdb 调试信息。
-nostdinc：生成OS时不应包含C语言标准库函数，需要自己实现，因此对于C文件里包含的头文件应给出头文件所在目录，如-Ikern/init/、-Ikern/driver/，已-I开头+文件夹表示寻找头文件的路径。
-fno-stack-protector：禁用堆栈保护器。

(2)通过ld，将目标文件链接，生成kernel可执行文件。
使用ld命令链接上面生成的各目标文件，并根据tools/kernel.ld脚本文件进行链接，链接后生成bin/kernel即OS内核文件。

+ ld bin/kernel
ld -m    elf_i386 -nostdlib -T tools/kernel.ld -o bin/kernel  obj/kern/init/init.o obj/kern/libs/stdio.o obj/kern/libs/readline.o obj/kern/debug/panic.o obj/kern/debug/kdebug.o obj/kern/debug/kmonitor.o obj/kern/driver/clock.o obj/kern/driver/console.o obj/kern/driver/picirq.o obj/kern/driver/intr.o obj/kern/trap/trap.o obj/kern/trap/vectors.o obj/kern/trap/trapentry.o obj/kern/mm/pmm.o  obj/libs/string.o obj/libs/printfmt.o

由上一问可知，生成bootloader时，调用了sign程序用于生成一个符合规范的硬盘主引导扇区，因此我们截取了sign.c的部分代码来进行分析。

    char buf[512];
    memset(buf, 0, sizeof(buf));
    FILE *ifp = fopen(argv[1], "rb");
    int size = fread(buf, 1, st.st_size, ifp);
    if (size != st.st_size) {
        fprintf(stderr, "read '%s' error, size is %d.\n", argv[1], size);
        return -1;
    }
    fclose(ifp);
    buf[510] = 0x55;  //把buf数组的最后两位置为 0x55, 0xAA
    buf[511] = 0xAA;
    FILE *ofp = fopen(argv[2], "wb+");
    size = fwrite(buf, 1, 512, ofp);
    if (size != 512) { //大小为512字节
        fprintf(stderr, "write '%s' error, size is %d.\n", argv[2], size);
        return -1;
    }
    fclose(ofp);
    printf("build 512 bytes boot sector: '%s' success!\n", argv[2]);

该程序主要功能是将输入文件的第511个字节设为0x55，第512个字节设为0xAA。因此系统对于主引导扇区所要求的是：大小为512字节，第510个（倒数第二个）字节是0x55，第511个（倒数第一个）字节是0xAA，其余字节填充为0。

为了熟悉使用qemu和gdb进行的调试工作，我们进行如下的小练习：
从CPU加电后执行的第一条指令开始，单步跟踪BIOS的执行。
在初始化位置0x7c00设置实地址断点,测试断点正常。
从0x7c00开始跟踪代码运行,将单步跟踪反汇编得到的代码与bootasm.S和 bootblock.asm进行比较。
自己找一个bootloader或内核中的代码位置，设置断点并进行测试。

提示：参考附录“启动后第一条执行的指令”，可了解更详细的解释，以及如何单步调试和查看BIOS代码。
提示：查看 labcodes_answer/lab1_result/tools/lab1init 文件，用如下命令试试如何调试bootloader第一条指令：

 $ cd labcodes_answer/lab1_result/
 $ make lab1-mon

相关背景知识：
BIOS启动过程：当计算机加电后，一般不直接执行操作系统，而是执行系统初始化软件完成基本IO初始化和引导加载功能。简单地说，系统初始化软件就是在操作系统内核运行之前运行的一段小软件。对于Intel 80386的体系结构而言，PC机中的系统初始化软件由BIOS 和位于软盘/硬盘引导扇区中的OS Boot Loader一起组成。以Intel 80386为例，计算机加电后，CPU从物理地址0xFFFFFFF0（由初始化的CS：EIP确定，此时CS和IP的值分别是0xF000和0xFFF0)）开始执行。在0xFFFFFFF0这里只是存放了一条跳转指令，通过跳转指令跳到BIOS例行程序起始点。BIOS做完计算机硬件自检和初始化后，会选择一个启动设备（例如软盘、硬盘、光盘等），并且读取该设备的第一扇区(即主引导扇区或启动扇区)到内存一个特定的地址0x7c00处，然后CPU控制权会转移到那个地址继续执行。至此BIOS的初始化工作做完了，进一步的工作交给了ucore的bootloader。

实模式：Intel早期的8086 CPU提供了20根地址线,可寻址空间范围即0~$2^{20}$的1MB内存空间。但8086的数据处理位宽位16位，无法直接寻址1MB内存空间，所以8086提供了段地址加偏移地址的地址转换机制。其内存寻址方式由16位段寄存器的内容乘以16（10H），当做段基地址，再加上16位偏移地址形成20位的物理地址。其最大寻址空间1MB，最大分段64KB。公式表示为：物理地址（physicaladdress）=段值（segment）*16+偏移（offset）。当CPU加电后，会进入实模式，实模式下所有的段都是可以读、写和可执行的，以此来在内存中寻找指令并执行。

正文：
由于要对BIOS进行单步跟踪，我们会用到到gdb，因此我们先查看Makefile中关于debug的代码。

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

我们可以看到debug部分的代码是通过tools/gdbinit配置文件中的命令使gdb进行调试的，其中内容为：

file bin/kernel //加载kernel，即加载符号信息
target remote :1234 //对qeum进行连接
break kern_init //将断点设在内核代码的入口函数
continue

由于要让BIOS进行单步调试，我们需要将其修改为：

set architecture i8086 //CPU以16位实模式启动
target remote :1234 //对qeum进行连接

根据背景知识的介绍，我们对cs和eip进行查看，可以看到第一条指令的cs内容为0xf000，eip(pc)内容为0xfff0，一开始CPU以16位的实模式启动，因此物理地址=cs*16+eip=0xffff0即cs:eip=0xf000:0xfff0=0xffff0。
因此地址0xffff0为BIOS的入口地址，该地址存放的指令为跳转指令ljmp，跳转到0xf000:0xe05b=0xfe05b处执行BIOS代码。

对BIOS的执行进行单步追踪：


从0xfe05b此处开始，执行BIOS程序，当BIOS做完计算机硬件自检和初始化后，BIOS读取首扇区MBR上的bootloader代码，并将其放到0x7c00处，进而cpu控制权交给bootloader进行执行。从0xfcf24开始，BIOS将权限交给了bootloader。

在0x7c00处设置一个断点，执行c运行到断点，用x/5i $pc查看0x7c00后5条汇编代码，与bootasm.S中前五条指令相同，证实断点正常（也可在gdbinit中修改）。

还是查看Makefile中关于debug的代码，在调用qemu时增加-d in_asm -D $(BINDIR)/q.log参数，这样可以将执行过的指令保存在q.log中。

然后make debug，进入gdb中进行调试，在q.log中查看0x7c00处的反汇编代码：

打开bootasm.S和bootblock.asm文件，发现两个文件的代码其实是一样的，且与q.log中0x7c00后的代码是一致。

修改gdbinit，将断点设置到bootmain：

file obj/bootblock.o
target remote :1234
break bootmain
continue

gdb可以正常调试：

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

提示：需要阅读小节“保护模式和分段机制”和lab1/boot/bootasm.S源码，了解如何从实模式切换到保护模式，需要了解：
为何开启A20，以及如何开启A20。
如何初始化GDT表。
如何使能和进入保护模式。

相关背景知识：
bootloader需要完成的工作：
切换到保护模式，启用分段机制；
读磁盘中ELF执行文件格式的ucore操作系统到内存；
显示字符串信息；
把控制权交给ucore操作系统。

保护模式：由前面介绍实模式可知，通过实模式的segment:offset寻址方式最大地址为0xffff<<4+0xffff=0x10ffef，超出了20根地址线物理寻址能力，在8086中会发生地址回卷，最高的第20位被丢掉（从0开始），实际物理内存地址为0x0ffef。随后的处理器，如80286、80386都拥有更多的地址线，为使得其在实模式下与8086表现保持一致，实模式下使得第20根地址线恒为0，发生回卷时，则物理地址不会超出1M的内存空间。因此80386提供了方式用于是否打开A20地址线，若cpu进入保护模式需打开A20。因此，只有在保护模式下，80386的全部32根地址线有效，可寻址高达4G字节的线性地址空间和物理地址空间，可访问64TB的逻辑地址空间，可采用分段存储管理机制和分页存储管理机制。这不仅为存储共享和保护提供了硬件支持，而且为实现虚拟存储提供了硬件支持。通过提供4个特权级和完善的特权检查机制，既能实现资源共享又能保证代码数据的安全及任务的隔离。

分段存储管理机制：分段机涉及4个关键内容：逻辑地址、段描述符（描述段的属性）、段描述符表（包含多个段描述符的“数组”）、段选择子（段寄存器，用于定位段描述符表中表项的索引）。
其中段描述符格式如下：
段基地址：规定线性地址空间中段的起始地址。在80386保护模式下，段基地址长32位。因为基地址长度与寻址地址的长度相同，所以任何一个段都可以从32位线性地址空间中的任何一个字节开始，而不像实方式下规定的边界必须被16整除。
段界限：规定段的大小。在80386保护模式下，段界限用20位表示，而且段界限可以是以字节为单位或以4K字节为单位。
段属性：确定段的各种性质。
①段属性中的粒度位（Granularity），用符号G标记。G=0表示段界限以字节位位单位，20位的界限可表示的范围是1字节至1M字节，增量为1字节；G=1表示段界限以4K字节为单位，于是20位的界限可表示的范围是4K字节至4G字节，增量为4K字节。
②类型（TYPE）：用于区别不同类型的描述符。可表示所描述的段是代码段还是数据段，所描述的段是否可读/写/执行，段的扩展方向等。
描述符特权级（Descriptor Privilege Level）（DPL）：用来实现保护机制。
③段存在位（Segment-Present bit）：如果这一位为0，则此描述符为非法的，不能被用来实现地址转换。如果一个非法描述符被加载进一个段寄存器，处理器会立即产生异常。图5-4显示了当存在位为0时，描述符的格式。操作系统可以任意的使用被标识为可用（AVAILABLE）的位。
④已访问位（Accessed bit）：当处理器访问该段（当一个指向该段描述符的选择子被加载进一个段寄存器）时，将自动设置访问位。操作系统可清除该位。

其中段描述表分为全局段描述符表（GDT）与本地段描述符表（LDT），而ucore中只使用了GDT。
全局段描述符寄存器（GDTR）格式如下所示，分为32位基址与16位界限：

地址空间：
逻辑地址空间：从应用程序的角度看，逻辑地址空间就是应用程序员编程所用到的地址空间。
物理地址空间：从操作系统的角度看，CPU、内存硬件（通常说的“内存条”）和各种外设是它主要管理的硬件资源而内存硬件和外设分布在物理地址空间中。
虚拟地址空间：一台计算机只有一个物理地址空间，但在操作系统的管理下，每个程序都认为自己独占整个计算机的物理地址空间。为了让多个程序能够有效地相互隔离和使用物理地址空间，引入线性地址空间（也称虚拟地址空间）的概念。
三种地址关系如下：
启动分段机制，未启动分页机制：逻辑地址–> (分段地址转换) -->线性地址==物理地址
启动分段和分页机制：逻辑地址–> (分段地址转换) -->线性地址–>(分页地址转换) -->物理地址

保护模式下的特权级：
CPL：当前特权级（Current Privilege Level) 保存在CS段寄存器（选择子）的最低两位，CPL就是当前活动代码段的特权级，并且它定义了当前所执行程序的特权级别。
DPL：描述符特权（Descriptor Privilege Level） 存储在段描述符中的权限位，用于描述对应段所属的特权等级，也就是段本身真正的特权级。
RPL：请求特权级RPL(Request Privilege Level) RPL保存在选择子的最低两位。RPL说明的是进程对段访问的请求权限，意思是当前进程想要的请求权限。RPL的值由程序员自己来自由的设置，并不一定RPL>=CPL，但是当RPL < CPL时，实际起作用的就是CPL了，因为访问时的特权检查是判断：max(RPL,CPL)<=DPL是否成立，所以RPL可以看成是每次访问时的附加限制，RPL=0时附加限制最小，RPL=3时附加限制最大。

开启A20地址线（参考bootasm.S）：
等待8042 Input buffer为空；
发送Write 8042 Output Port （P2）命令到8042 Input buffer；
等待8042 Input buffer为空；
将8042 Output Port（P2）得到字节的第2位置1，然后写入8042 Input buffer。

正文：
首先，我们来看bootloader的组成，分别为
asm.h（是bootasm.S汇编文件所需要的头文件，主要是一些与X86保护模式的段访问方式相关的宏定义）
bootasm.S（定义并实现了bootloader最先执行的函数start，开启A20，设置GDT，并进入保护模式，进入bootmain函数）
bootmain.c（加载kernel到内存，然后跳转到ucore的入口处执行）。
本练习中，我们仅需分析前两个文件。

bootasm.S一开始先定义了三个常量

PROT_MODE_CSEG和PROT_MODE_DSEG分别作为内核代码段、数据段的选择子。并且由图可知，二者分别指向GDT[1]和GDT[2]，RPL为0，CPL为0。而CRO_PE_ON则是切换到保护模式时的使能标志。
选择子格式如下：

bootloader入口地址为start函数，此时处于实模式。首先需要关闭中断，避免产生中断被BIOS中断处理程序处理。之后将各个段寄存器基址设为0。

# start address should be 0:7c00, in real mode, the beginning address of the running bootloader
.globl start
start:
.code16                                             # 16位实模式
    cli                                             # 关闭中断
    cld                                             # 从低地址到高地址

    # Set up the important data segment registers (DS, ES, SS). #初始化段寄存器
    xorw %ax, %ax                                   # 各段寄存器基址设为0
    movw %ax, %ds                                   # -> Data Segment
    movw %ax, %es                                   # -> Extra Segment
    movw %ax, %ss                                   # -> Stack Segment

在分段存储管理机制的保护模式下，每个段由如下三个参数进行定义：段基地址、段界限和段属性。而asm.h文件通过宏的方式来定义了初始化段描述符的宏函数，因此我们来查看asm.h：

/* Normal segment */
#define SEG_NULLASM                                             \
    .word 0, 0;                                                 \
    .byte 0, 0, 0, 0

SEG_NULLASM中.word代表生成一个字长度（此处2字节，由16位实模式所决定)的数, 而.byte代表生成一个字节的数。因此SEG_NULLASM声明要生成两个字（每个字2字节）长度的数0，接着生成4个字节的数0。

#define SEG_ASM(type,base,lim)                                  \
    .word (((lim) >> 12) & 0xffff), ((base) & 0xffff);          \
    .byte (((base) >> 16) & 0xff), (0x90 | (type)),             \
        (0xC0 | (((lim) >> 28) & 0xf)), (((base) >> 24) & 0xff)

SEG_ASM中，两个word分别定义为0xffff和0x0000。前者是0xffffffff右移12位变为0x000fffff，然后与0x0000ffff项相与得到0xffff，而后者是0x0000&0xffff=0x0000。对于后面的4个byte，第一个为0x00（段基址23~16 ），第二个为0x90（ P=1、DPL=00、S=1、TYPE=type），第三个为0xcf（G=1、D/B=1、L=0、AVL=0、段界限19~16 ），第四个为0x00（段基址31~24）。

再结合上图，由此我们可知这个段描述符大小为8字节，即64位，0xffff对应段描述符0-15位，0x0000对应16-31位，然后4个byte对应高位。所以最后得到的段基地址就是0x00000000。

了解了段描述符如何初始化后，我们再次回到bootasm.S，查看GDT的初始化。

# Bootstrap GDT，设置GDT表
.p2align 2                                          # force 4 byte alignment，强制4字节对齐
gdt:                                                    
    SEG_NULLASM                                     # null seg，空段
    SEG_ASM(STA_X|STA_R, 0x0, 0xffffffff)           # code seg for bootloader and kernel
    SEG_ASM(STA_W, 0x0, 0xffffffff)                 # data seg for bootloader and kernel

gdtdesc:
    .word 0x17                                      # sizeof(gdt) - 1，GDT边界，三个段，共3 * 8 = 24 B，值为24 - 1 = 23 (0x17)
    .long gdt                                       # address gdt，GTD基址，长度32

GDT被设置为４字节对齐，仅定义了GDT[0]（空段）、GDT[1]（内核代码段）、GDT[2]（内核数据段）。代码段和数据段基址均为0，总长度都为整个内存空间4G大小，因此逻辑地址=线性地址。

初始化GDT后，通过lgdt指令来将GDT信息写入GDTR。此时我们已经完成bootloader切换到保护模式的全部准备工作。开启保护模式仅需要打开控制寄存器CR0中相应的标志位，通过异或之前定义的CR0_PE_ON即可实现。

    # Switch from real to protected mode, using a bootstrap GDT
    # and segment translation that makes virtual addresses
    # identical to physical addresses, so that the
    # effective memory map does not change during the switch.
    lgdt gdtdesc    #将GDT信息写入GDTR。
    movl %cr0, %eax
    orl $CR0_PE_ON, %eax  
    movl %eax, %cr0  #打开保护模式

此时CPU真正进入了32位模式，即保护模式。进入该模式后，ljmp指令重新初始化了代码段寄存器CS的值，其中CS的前12位为0x001，将其乘以8为0x008作为gdt表的偏移值来选择段描述符，所以其选择即为CS段描述符，其Base为0，偏移地址即为protcseg的地址。需要注意的是，由于我们bootloader程序代码段在实模式加载到内存时其从0x7c00的物理地址向高位内存加载，故当我们在分段模式下设定Base地址为0时，偏移地址为protcseg地址时，在保护模式下正好能运行bootloader中protcseg段代码。

    # Jump to next instruction, but in 32-bit code segment.
    # Switches processor into 32-bit mode.
    ljmp $PROT_MODE_CSEG, $protcseg

随后将所有段寄存器设置为PROT_MODE_DSEG（指向内核数据段）。将栈区域设置为0x00~0x7c00，即bootloader之下都是栈的空间，然后使用call指令执行bootmain.c，开始加载kernel。bootmain函数正常情况不会返回，如果返回肯定是bootloader产生错误，进入死循环。

通过阅读bootmain.c，了解bootloader如何加载ELF文件。通过分析源代码和通过qemu来运行并调试bootloader&OS，来回答
bootloader如何读取硬盘扇区的？
bootloader是如何加载ELF格式的OS？
提示：可阅读“硬盘访问概述”，“ELF执行文件格式概述”这两小节。

相关背景知识：
磁盘的读取方式主要有两种CHS(Cylinder Head Sector)、LBA(Logical Block Address)，CHS通过柱面-磁头-扇区三个值进行定位，较为麻烦。而LBA方式进一步屏蔽了细节，将磁盘按照扇区号进行统一编址，访问时给出扇区号即可。考虑到实现的简单性，bootloader的访问硬盘都是LBA模式的PIO（Program IO）方式，即所有的IO操作是通过CPU访问硬盘的IO地址寄存器完成。
一般主板有2个IDE通道，每个通道可以接2个IDE硬盘。访问第一个硬盘的扇区可设置IO地址寄存器0x1f0-0x1f7实现的，具体参数见下表。一般第一个IDE通道通过访问IO地址0x1f0-0x1f7来实现，第二个IDE通道通过访问0x170-0x17f实现。每个通道的主从盘的选择通过第6个IO偏移地址寄存器来设置。
磁盘IO地址和对应功能(第6位：为1=LBA模式，为0=CHS模式，第7位和第5位必须为1)

通过0x1f6端口可以设置主从盘、访问方式以及扇区号27—24位。

正文：
一个扇区大小为512字节，读一个扇区的流程（可参看boot/bootmain.c中的readsect函数实现）大致如下：
(1)等待磁盘准备好。
(2)发出读取扇区的命令。
(3)等待磁盘准备好。
(4)把磁盘扇区数据读到指定内存。
因此我们来查看bootmain.c文件。
(1)等待磁盘准备好。

#define SECTSIZE        512
#define ELFHDR          ((struct elfhdr *)0x10000)      // scratch space

/* waitdisk - 等待磁盘准备就绪 */
static void
waitdisk(void) {
    while ((inb(0x1F7) & 0xC0) != 0x40)
        /* 死循环等待 */;
}

读取0x1f7端口来获取磁盘控制器状态，若第7位为1，表示磁盘正忙，需要等待，若第7位为0，第6位为1，表示准备就绪。

(2)发出读取扇区的命令。

(3)等待磁盘准备好。

/* readsect - read a single sector at @secno into @dst */
/* 读取编号为secno的一个扇区到dst地址处 */
static void
readsect(void *dst, uint32_t secno) {
    // 等待磁盘准备就绪
    waitdisk();

    outb(0x1F2, 1);                         //读取扇区数目1
    outb(0x1F3, secno & 0xFF);              //读取扇区号0~7位
    outb(0x1F4, (secno >> 8) & 0xFF);       //读取扇区号8~15位
    outb(0x1F5, (secno >> 16) & 0xFF);      //读取扇区号16~23位
    outb(0x1F6, ((secno >> 24) & 0xF)|0xE0);
    //掩码0xF将扇区号28~31位置零，仅保留24~27位。异或0xE0避开了IO端口第4位，目的是读取主盘。
    outb(0x1F7, 0x20);                      //0x20为读取扇区命令

    // 等待磁盘准备就绪
    waitdisk();

    // 读取该扇区
    insl(0x1F0, dst, SECTSIZE / 4); //SECTISE被定义为512字节，而insl每次读取4字节,所以SECTISE要除4。
}

readsect是用来读取一个扇区的函数，其中outb和insl函数都是采用内联汇编的方式，将常用的汇编操作封装为函数的函数，有利于复用，头文件x86.h为一些常用的内联汇编函数封装。

(4)把磁盘扇区数据读到指定内存。

/* *
 * readseg - read @count bytes at @offset from kernel into virtual address @va,
 * might copy more than asked.
 * 从内核的offset偏移处读取count个字节到虚拟地址va中，可能复制的字节数多于请求的count个。
 * */
static void
readseg(uintptr_t va, uint32_t count, uint32_t offset) {
    uintptr_t end_va = va + count;

    // 向下对准到磁盘边界
    va -= offset % SECTSIZE;

    // 将偏移量转为扇区号，内核始于扇区1
    uint32_t secno = (offset / SECTSIZE) + 1;

    // If this is too slow, we could read lots of sectors at a time.
    // We'd write more to memory than asked, but it doesn't matter --
    // we load in increasing order.
    for (; va < end_va; va += SECTSIZE, secno ++) {
        readsect((void *)va, secno);
    }
}

readseg函数提供的功能是从磁盘读取count字节数据到虚拟地址va中，但是读取硬盘是以512字节的扇区为单位的。所以实际读入的字节数很可能大于要求读入的字节数。考虑到readseg的偏移读取，通过va -= offset % SECTSIZE来向下对准到磁盘边界，如果读取磁盘中内核文件的起始数据不位于一个扇区的开始，应将va减小，使得完整读取一个扇区后，原va处正好就是内核文件经过偏移offset后的起始数据。

相关背景知识：
我们首先得了解何为ELF，ELF(Executable and linking format)文件格式是Linux系统下的一种常用目标文件(object file)格式，有三种主要类型:可执行文件，可重定位文件，共享目标文件。本实验的OS文件类型即为可执行文件，因此我们仅分析可执行文件。可执行文件用于提供程序的进程映像，加载的内存执行，主要由ELF文件头、程序头、以及相应段组成，而ELF header在文件开始处描述了整个文件的组织。
ELF的文件头包含整个执行文件的控制结构，其定义在libs/elf.h中：

#define ELF_MAGIC    0x464C457FU            // "\x7FELF" in little endian  ELF魔数，小端存储

/* ELF文件头 */
struct elfhdr {
    uint32_t e_magic;     // ELF魔数，7f 45 4c 46
    uint8_t  e_elf[12];    // ELF格式信息，32/64位，大端/小端存储
    uint16_t e_type;      // 1=relocatable, 2=executable, 3=shared object, 4=core image
    uint16_t e_machine;   // ELF体系结构类型，3=x86, 4=68K, etc.
    uint32_t e_version;   // 文件版本，总为1
    uint32_t e_entry;     // 可执行程序入口虚拟地址
    uint32_t e_phoff;     // 程序头在文件内的字节偏移量
    uint32_t e_shoff;     // 节头表在文件内的字节偏移量
    uint32_t e_flags;     // 处理器相关标识，通常为0
    uint16_t e_ehsize;    // ELF header文件头字节大小
    uint16_t e_phentsize; // 程序头每个条目(entry)的字节大小
    uint16_t e_phnum;     // 程序头条目数量，即段的个数
    uint16_t e_shentsize; // 节头表每个条目(entry)的字节大小
    uint16_t e_shnum;     // 节头表中条目的数量，即节的个数
    uint16_t e_shstrndx;  // string name table在节头表中的索引index
};

程序头表则用来描述程序中的各段信息，如代码段、数据段等，这些段组成了最终在内存中执行的程序。程序头表提供了各段在虚拟地址空间和物理地址空间中的大小、位置、标志、访问授权和对齐方面的信息。程序头表同样定义在elf.h中：

struct proghdr {
    uint32_t p_type;   // 段类型， 如可加载的代码段或数据段、动态链接信息段等
    uint32_t p_offset; // 本段在文件内的其实偏移
    uint32_t p_va;     // 本段在内存中的起始虚拟地址
    uint32_t p_pa;     // 本段在内存中的起始物理地址，不使用
    uint32_t p_filesz; // 本段在文件中的大小
    uint32_t p_memsz;  // 本段在内存中的大小（如果包含bss节，会更大）
    uint32_t p_flags;  // 本段相关的标志，如读/写/执行
    uint32_t p_align;  // 对齐，和硬件页大小一致；如果为0或1，表示不需要对齐。否则，p_align应该是2的正整数幂，p_va和p_offset在对p_align取模后应相等
};

正文：
我们通过readelf -e kernel来查看kernel ELF文件相关信息，下面是ELF文件头的信息：

可见程序入口虚拟地址为0x100000，程序头表偏移为52B，程序头表条目为3。
我们再来查看程序头表的信息：

可见一共创建了三个段，第一个段是代码段，第二个段是数据段，第三个段是空段，这个与前面GDT的分析相符。
现在我们再来分析bootmain.c，其载入OS的代码如下：

分析可得载入流程为：
（1）先从硬盘读取一页大小数据（4K）到内存0x10000地址处，即读取kernel的ELF文件头和程序头表加载到ELFHDR（0x10000）处。
（2）然后通过ELF文件头的魔数判断ELF文件格式是否合法。
（3）如果格式合法就根据kernel中的ELF文件头和程序头表中的信息将kernel各段加载到内存中。
（4）最后根据ELF文件头储存的入口信息，找到内核的入口。

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

……
ebp:0x00007b28 eip:0x00100992 args:0x00010094 0x00010094 0x00007b58 0x00100096
    kern/debug/kdebug.c:305: print_stackframe+22
ebp:0x00007b38 eip:0x00100c79 args:0x00000000 0x00000000 0x00000000 0x00007ba8
    kern/debug/kmonitor.c:125: mon_backtrace+10
ebp:0x00007b58 eip:0x00100096 args:0x00000000 0x00007b80 0xffff0000 0x00007b84
    kern/init/init.c:48: grade_backtrace2+33
ebp:0x00007b78 eip:0x001000bf args:0x00000000 0xffff0000 0x00007ba4 0x00000029
    kern/init/init.c:53: grade_backtrace1+38
ebp:0x00007b98 eip:0x001000dd args:0x00000000 0x00100000 0xffff0000 0x0000001d
    kern/init/init.c:58: grade_backtrace0+23
ebp:0x00007bb8 eip:0x00100102 args:0x0010353c 0x00103520 0x00001308 0x00000000
    kern/init/init.c:63: grade_backtrace+34
ebp:0x00007be8 eip:0x00100059 args:0x00000000 0x00000000 0x00000000 0x00007c53
    kern/init/init.c:28: kern_init+88
ebp:0x00007bf8 eip:0x00007d73 args:0xc031fcfa 0xc08ed88e 0x64e4d08e 0xfa7502a8
: -- 0x00007d72 –
……

请完成实验，看看输出是否与上述显示大致一致，并解释最后一行各个数值的含义。

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

要求完成函数kern/debug/kdebug.c::print_stackframe的实现，提交改进后源代码包（可以编译执行），并在实验报告中简要说明实现过程，并写出对上述问题的回答。

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

相关背景知识：
函数堆栈：堆栈是函数运行时的内存空间，由高地址向低地址增长，ebp寄存器存储栈底地址，esp寄存器存储栈顶地址，始终指向栈顶元素；栈从高地址向地址增长。
函数调用时主要经过以下步骤：

调用者：
（1）将被调用函数的参数从右向左依次入栈。
（2）执行call命令，将call命令的下一条指令地址，也即返回地址，压栈，同时跳转到被调用函数执行。
被调用函数：
（1）pushl %ebp：将调用者的栈底地址入栈，便于返回到调用者继续执行。
（2）movl %esp, %ebp：%ebp指向当前栈顶，也即与%esp指向相同，此函数的堆栈就此建立函数执行，临时变量压入堆栈。
（3）movl %ebp, %esp：%esp指向该函数的栈底。
（4）popl %ebp：将%ebp栈底指针重新指向调用者函数的栈底地址。
（5）ret：被调用函数从栈顶弹出返回地址，返回到调用函数继续执行。

void
print_stackframe(void) {
     /* LAB1  : STEP 1 */
     /* (1) call read_ebp() to get the value of ebp. the type is (uint32_t);
      * (2) call read_eip() to get the value of eip. the type is (uint32_t);
      * (3) from 0 .. STACKFRAME_DEPTH
      *    (3.1) printf value of ebp, eip
      *    (3.2) (uint32_t)calling arguments [0..4] = the contents in address (uint32_t)ebp +2 [0..4]
      *    (3.3) cprintf("\n");
      *    (3.4) call print_debuginfo(eip-1) to print the C calling function name and line number, etc.
      *    (3.5) popup a calling stackframe
      *           NOTICE: the calling funciton's return addr eip  = ss:[ebp+4]
      *                   the calling funciton's ebp = ss:[ebp]
      */
    uint32_t ebp=read_ebp(),eip=read_eip();            //获得ebp与eip的初值
    int i,j;
    for(i=0;i