操作系统实验
Lab1
目录
1.思考题解答
2.难点分析
3.思考体会
思考题解答
Thinking 1.1
（1）编译工具使用
使用实验环境中的原生 x86 工具
链（gcc、ld、readelf、objdump）等对 hello.c 进行处理可观察到 预处理，编译，链接 的全过程，最后生成的 hello 文件可使用./hello执行。
使用MIPS 交叉编译工具链（带有 mips-linux-gnu 的前缀）对 hello.c进行处理，预处理生成的文件与使用 x86 工具处理的几乎一样，但其生成的目标文件和可执行文件无法使用 x86 架构下的 objdump 反编译，且最终的可执行文件无法通过./hello执行，这是由于 x86 和 mips 架构存在差异。
（2）objdump的参数意义
- objdump -D <file(s)>: 将代码段反汇编；
- objdump -S <file(s)>: 将代码段反汇编的同时，将反汇编代码与源代码交替显示，编译时需要使用-g参数，即需要调试信息；
- objdump -C <file(s)>: 将C++符号名逆向解析；
- objdump -l <file(s)>: 反汇编代码中插入文件名和行号；
- objdump -j section <file(s)>: 仅反汇编指定的section。
Thinking 1.2
(1) readelf 对 mos 的解析结果
0:0x0
1:0x80010000
2:0x800121a0
3:0x800121b8
4:0x800121d0
5:0x0
6:0x0
7:0x0
8:0x0
9:0x0
10:0x0
11:0x0
12:0x0
13:0x0
14:0x0
15:0x0
16:0x0
17:0x0
(2)对实验中 readelf 的探究
hello.c的编译链接选项：
- -m32：编译出来的是32位程序，既可以在32位操作系统运行，又可以在64位操作系统运行。
- -static: 选择静态库链接。
- -g: 支持调试
官方的 readelf 工具和我们在实验中的 readelf 程序较大的不同是**官方 readelf 工具支持解析64位 ELF 文件，而我们实验的 readelf 只可解析32位 ELF 文件；
编译选项控制生成 hello 为 32位 ELF 文件，我们实验编译产生的 readelf 为 64位 ELF 文件，自然的，我们编写的 readelf 程序是不能解析 readelf 文件本身的，而系统工具 readelf 则可以解析。
Thinking 1.3
答：
在实验中，GXemul 仿真器支持直接加载 ELF 格式的内核，也
就是说，GXemul 已经提供了 bootloader 的引导（启动）功能；MOS 操作系统不需要再实现 bootloader 的功能。在 MOS 操作系统的运行第一行代码前，我们就已经拥有一个正常的程序运行环境，内存和一些外围设备都可以正常使用。
GXemul 支持加载 ELF 格式内核，所以启动流程被简化为加载内核到内存，之后跳转到内核的入口，启动就完成了。
难点分析
在 lab1 中，我认为难度较大的实验操作如下：
- 理清操作系统启动的全过程，找到不同操作系统启动间的共性，生成启动流程图。
- 较大型程序体系的把控和复杂 Makefile 程序的解析。
- 最后的 print.c 函数的补全，考查了对 c 语言指针和变长类型的掌握能力，编程中需考虑的细节情况较多。
思考体会
本次实验中，我从课程组提供的教程和简易操作系统的代码出发，学习了操作系统启动的全过程，对操作系统的启动流程，可执行文件的编译，Makefile 的编写有了更加深入的理解。
对于实验最后要求我们编写的 print.c 程序以支持 C 标准中的 printf 函数这一部分，目前的 print.c 还不支持长型、浮点、非十进制的读入，仍需进一步完善。
在附录中，我对于实验中出现的一些陌生的宏定义有了大致的了解，对代码的理解加深了一些。
