BUAA操作系统lab1

Lab1实验报告

一、思考题

Thinking 1.1

尝试分别使用实验环境中的原生 x86 工具链（gcc、ld、readelf、objdump 等）和 MIPS交叉编译工具链（带有mips-linux-gnu- 前缀，如 mips-linux-gnu-gcc、mips-linux-gnu-ld），重复其中的编译和解析过程，观察相应的结果，并解释其中向objdump传入的参数的含义
objdump是一个强大的二进制文件分析工具，常用于反汇编和查看目标文件的详细信息，常用的参数有以下几个：

• -d：反汇编可执行段
• -D：反汇编所有段
• -S：在反汇编代码中混合显示源代码
• -j：指定要反汇编的段
• -g：显示调试信息
• -f：显示文件头信息，包括文件类型、架构、字节序等

在过程中，我使用最多的是-D和-S选项，用来将目标文件反汇编出来。
我在使用原生x86工具链和MIPS交叉编译工具链并观察相应结果时发现，它们最大的差异就是相应架构的不同，x86工具链适用于x86架构，而MIPS工具链适用于MIPS架构。
比如，我编写了一个简单的C程序，如下：

#include<stdio.h>
int main(){
  printf("Hello,World!\n");
  return 0;
}

使用原生工具链gcc正常编译出可执行文件，即”gcc hello.c”后，通过file查看文件类型，结果如下：

可以发现其是一个64位的x86-64架构的ELF可执行文件，同时用readelf查看其信息，结果如下：

再运用gcc的-c选项只编译不链接并使用objdump进行反汇编后，相应结果如下：

可见其中的指令全是x86指令集架构中的指令。
再使用MIPS交叉编译工具链，用mips-linux-gnu-gcc编译出可执行文件，通过file查看文件类型，结果如下：

其是一个32位的mips架构的ELF可执行文件，使用readelf查看其信息，结果如下：

再只对其编译不链接并使用objdump进行反汇编，结果如下：

其指令全是mips指令集架构中的指令。

Thinking 1.2

也许你会发现我们编写的readelf程序是不能解析readelf 文件本身的，而我们刚才介绍的系统工具readelf 则可以解析，这是为什么呢？
首先查看Makefile：

可以发现，制作readelf和hello的语句选项并不相同，制作hello时多了”-m32”、”-static”、”-g”三个选项，指定了目标文件是32位架构，且其为静态链接。再分别查看hello和readelf的文件头：


可以发现hello确实是32位架构，而readelf是64位架构，而我们整个实验是在mips32位架构下进行的，所以我们自己写的readelf可以解析hello而不能解析自己

Thinking 1.3

在理论课上我们了解到，MIPS体系结构上电时，启动入口地址为0xBFC00000（其实启动入口地址是根据具体型号而定的，由硬件逻辑确定，也有可能不是这个地址，但一定是一个确定的地址），但实验操作系统的内核入口并没有放在上电启动地址，而是按照内存布局图放置。思考为什么这样放置内核还能保证内核入口被正确跳转到？
我们的整个实验是在QEMU模拟器上运行的，在运行第一行代码之前，我们已经拥有了一个正常的程序运行环境，已经可以访问内存了，我们还设置好了相应节的位置和程序入口，因此可以直接通过访问内存来正确跳转到内核入口。

二、难点分析

个人觉得本次实验由于有很多理论上较为晦涩的东西，因此在啃实验指导书的时候十分痛苦，但真正到跳板机上做实验的时候很多东西并没有用到，相应的难度降低了不少，但还是有一些困难的，个人总结下来有如下：

• ELF相关数据结构的定义的认识与理解
• 如何用指针去访问节和段
• 链接的逻辑
• print的实现逻辑
• MIPS内存如何布局

三、实验体会

在Lab1中，我学习了操作系统是如何启动的，其启动过程是一个十分纠结的过程，好在实验所用qemu模拟器省去了那纠结的过程，我还了解到ELF格式的相关定义，以及内存的布局，链接器的工作原理等，这些东西对一向对底层硬件和软件不怎么感冒的我来说理解起来有一定的难度，就算完成了实验之后仍然觉得这些过程、原理和结构异常复杂，因为所完成的实验几乎没有怎么涉及到这些过程。最具挑战性的是最后对printf函数功能的实现，这个部分也花费了我很多时间，一来是相关注释的提示太模糊，二是我最初的想法和注释的想法大相径庭，实现的角度很不一样，导致我在耗费了大量时间去揣测注释的意思，最后又因为语法等原因进行了一定时间的debug，但在看到输出和期望输出相同的那一瞬间，我还是发自内心的开心，并理解到其实现逻辑的合理性。