OS - Lab1实验报告

归档于2025年7月8日。

思考题

1.1

先回答objdump的参数作用：

• -D：显示所有反汇编结果。
• -S：在源码可以找到的情况下，将源码与反汇编结果一同输出：

我选择对mips-linux-gnu-gcc与gcc的结果进行比较。

直接看objdump的结果太费劲，我们用readelf观察编译结果的不同。最直观的结果，是头文件内容发生了变化：

使用readelf -S，观察地址，亦会发现不同：

1.2

• 解析结果如下：
  

• 阅读Makefile发现，我们的readelf编译时，是根据本机的运行环境进行编译的。
  

  不难发现，此时我们的系统架构为x86/64，是64位系统，生成的readelf是64位程序；而我们的hello根据-m32编译选项，生成的是32位程序。

  而我们编写的readelf是为了解析32位程序来写的，因此会出问题。

1.3

我们在上电的时候，第一个启动的并非操作系统内核，而是bootloader。自然，我们的内核起始地址不会是上电初始化的地址。

再看为什么可以找到内核的地址。阅读指导书发现，在启动过程中，我们的内核入口一定是在kseg0的一个确定位置处；在这个约定下，我们在bootloader中自然也会按这一规定编写程序，在跳转到内核这一步时，直接跳转到约定的地址。

难点分析

• 如何调试printk()。其相关的所有指令均针对MIPS体系结构，直接在跳板机环境下无法运行，使用gdb远程调试的效率有时亦不大理想。

  在本次实验中，我通过修改init.c，在其中测试printk()。在printk()内部，我也通过out()进行了传统的”printf()式调试。

• printk()实现的正确性检验。我选择使用printf()，对二者解析相同格式的结果进行比较。

• vim的高效使用。我编写readelf常常出现大小写按错的问题；没有自动补全很难办啊，目前这个问题也没有好的办法….还有查找定义与跳转，在每次进入子目录，检查子模块时，我们都要手动ctags，否则查不到定义；正在寻找更好的方法。

实验体会

完成本次Lab时，我注意到，我使用vim进行开发的效率并不理想。是时候多研究一下里面的快捷键了…

原创说明

本次实验报告为本人原创。