练习1、理解通过make生成执行文件的过程。
[练习1.1] 操作系统镜像文件 ucore.img 是如何一步一步生成的? 在proj1执行命令make V=可以得到make指令执行的过程
make V= + cc boot/bootasm.S gcc -Iboot/ -fno-builtin -Wall -ggdb -m32 -nostdinc -fno-stack-protector -Ilibs/ -Os -nostdinc -c boot/bootasm.S -o obj/boot/bootasm.o + cc boot/bootmain.c gcc -Iboot/ -fno-builtin -Wall -ggdb -m32 -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 -N -e start -Ttext 0x7C00 obj/boot/bootasm.o obj/boot/bootmain.o -o obj/bootblock.o 'obj/bootblock.out' size: 440 bytes build 512 bytes boot sector: 'bin/bootblock' success! dd if=/dev/zero of=bin/ucore.img count=10000 记录了10000+0 的读入 记录了10000+0 的写出 5120000字节(5.1 MB)已复制，0.0227439 秒，225 MB/秒 dd if=bin/bootblock of=bin/ucore.img conv=notrunc 记录了1+0 的读入 记录了1+0 的写出 512字节(512 B)已复制，0.000214966 秒，2.4 MB/秒
从这几条指令中可以看出需要生成ucore.img首先需要生成bootblock，而生成bootblock需要先生成bootmain.o和bootasm.o还有sign，这三个文件又分别由bootmain.c、bootasm.S、sigh.c来生成。
ld -m elf_i386 -N -e start -Ttext 0x7C00 obj/boot/bootasm.o obj/boot/bootmain.o – o obj/bootblock.o
这句话用于生成bootblock，elf_i386表示生成elf头，0x7C00为程序的入
口。
'obj/bootblock.out' size: 440 bytes
这句话表示生成的bootblock的文件大小，因为大小不到512字节，所以需要给blootblock填充，填充的功能在sign.c中有所体现，最后两字节设置为了0x55，0xAA
buf[510] = 0x55;
buf[511] = 0xAA;
FILE *ofp = fopen(argv[2], \); size = fwrite(buf, 1, 512, ofp);
[练习1.2] 一个被系统认为是符合规范的硬盘主引导扇区的特征是什么?
前面已经提到过：引导扇区的大小为512字节，最后两个字节为标志性结束字节0x55，0xAA，做完这样的检查才能认为是符合规范的磁盘主引导扇区。
Sign.c文件中有作检查：
if (size != 512) { }
fprintf(stderr, \, argv[2], size); return -1;
练习2：使用qemu执行并调试lab1中的软件。
[练习2.1] 从 CPU 加电后执行的第一条指令开始,单步跟踪 BIOS 的执行。 [练习2.2] 在初始化位置0x7c00 设置实地址断点,测试断点正常。
[练习2.3] 在调用qemu 时增加-d in_asm -D q.log 参数，便可以将运行的汇编指令保存在q.log 中。将执行的汇编代码与bootasm.S 和 bootblock.asm 进行比较，看看二者是否一致。
实验是基于老lab1/proj1做的，练习开始时是打算用命令行一句一句执行得到结果的，后来发现直接修改makefile和gdbinit可以大大提高调试效率。
于是在makefile中增加以下代码
lab1-mon: $(UCOREIMG) $(V)$(TERMINAL) -e \-serial null\ $(V)sleep 2 $(V)$(TERMINAL) -e \ tools/gdbinit\ -S –s是使得qemu在执行第一条指令之前停下来，在调用qemu时增加-d
in_asm -D q.log参数，便可以将运行的汇编指令保存在q.log中。然后sleep
两秒应该是给qemu充分的时间准备等待连接。接下来使用GDB调试工具，-tui提供了代码与命令行分屏查看的界面，tools/gdbinit中存放的是gdb调试file obj/bootblock.o target remote :1234 set architecture i8086 b *0x7c00 continue x /10i $pc 指令如下。
先是加载调试文件，然后连接qemu，设置8086的实模式，设置断点0x7c00，也就是bootloader的第一条指令，然后运行到断点。再显示接下来的10条指令。
运行结果图如下
很明显，断点位置的代码和boot.asm文件中的代码完全一致，说明断点设置成功。打开q.log文件看，看到了很奇葩的结果。能够看到cli,cld之类熟悉的指令，但是他们的地址以及出现的顺序都不是想象的那样(从0x0x00007c00k开始，第一条指令为cld)。
之后听大神解释，在q.log中进入BIOS之后的跳转地址与实际应跳转地址不相符，汇编代码也 与bootasm.S 和 bootblock.asm不相同。
可以通过make debug之后在qemu的控制台中输入x /10i $pc看到BIOS
执行bootloader部分的代码。
进过对比，这些代码 与bootasm.S与bootblock.asm中的代码完全一致。
练习3 分析bootloader 进入保护模式的过程。
在开启A20之前，BIOS还做了很多事:关中断、清除方向标志，给各个数据段清零。
cli # Set up the important data segment registers (DS, ES, SS). xorw %ax, %ax movw %ax, %ds movw %ax, %es movw %ax, %ss # Segment number zero # -> Data Segment # -> Extra Segment # Disable interrupts # String operations cld increment