本次主要采用是通过类似于在GNU/LD链接器的方式来完成整个任务。主要的参照依据是csapp中有关链接的相关说明。
目前的实际完成进度在于完成了符号的解析。但是后面的重定包括段重定位以及符号的重定位,目前还没有完成。
目前操作上来说,对于后续任务影响最大的内容在于之前任务的不正确完成,包括但不限于之前任务中埋藏的坑,比如说文件不能正确识别,将 1B 认定成为 一个16进制数而导致对于加载的文件中的align的错误判断,甚至还将用于解释rust内部结构体的自动align用于解释这里所出现的人为导致的align。
由于其他因素的影响,我在前半段时间其实没有过多的参与到其中来,近几天才加入到课题中。在参加课题之前其实对于libc,musl,甚至是elf文件没有什么过多的了解。简单的了解了下整个过程,本来看了下还想先直接用ld将对应的库链接好之后再放到arceos上读取(这是郝淼同学的实现思路),但是想到在 ld 将各种对象文件链接起来之后,实际上最后在使用的时候还是需要调用链接器 [–dynamic-linker可以指定对应链接器的地址] (当时实际上没想到可以直接实现链接器最后被调用的功能)。后面就按照实现一个链接器的想法继续实验。
目前主要使用 elf crates 实现了如下效果:
- 能够对于脚本中的符号进行重定位
目前对于重定位的操作实现尚未完成,根据要求,每一步实现实际上都需要遍历多次,更别提最原始的实现中由于对象文件的顺序引起的问题可能也需要往复遍历,正在尝试优化算法以及修改elf crates使之有着更好的体验。
未来工作可能没有特别大的必要开展,原因如下,在相同情况下,就算最终能够实现了一个能够在arceos上运行的链接器也是没有必要的。
- 现有的基于GNU/LD的链接器可以比较好的行使其职能,重复实现一个实际上没有必要实现的链接器会丢失原先所实现的优化,同时因为测试相对于前者而言更少,反而可能会导致更多错误,然而在这种实现的链接器面前,除非同时支持大量的编译工具,否则意义实际上不太大,只能算是个展示玩具。
/// BLUE PRINT
///
/// 1. LOAD APPLICATION
/// 2. SYMBOL RESOLUTION: make sure all symbol has been meet.
/// 3. RELOCATION:
/// [1] RELOCATION SECTION:
/// merges all sections of the same type into a new aggregate section of the same typecombine
/// BC we only need SHT_PROGBITS thus not care about others (copy).
/// [2] RELOCATE SYMBOL REFERENCES IN SECTIONS:
/// Modify references to each symbol in code and data sections so that they point to the correct run-time address
下面的伪代码实际完成了符号加载工作,重定向部分的代码还没有开始实际测试,就算未来有按照这个方法实现的必要,类似郝淼同学重新实现 elf crates 甚至在原先基础上进行修改的行为是必要的,现有的调用过程太长,使用起来不太舒服。
直接通过 shdr.e_type 实现对于符号的定位,根据CSAPP的说明,使用多个集合对于符号进行处理,实现符号匹配效果
1 | match ehdr.e_type { |