感觉这次实验难度某种意义上很简单，因为实验流程很简单，代码量也很小。难就难在有关实验细节，感觉文档很多地方没有讲具体，具体实验中还有 bug，比如 test1 的重定位类型没有 R-X86-64-PC32，与文档描述不符。还有有关多个目标文件合并顺序的问题，文档里也没有细讲，我做实验时看 main 函数也有点迷糊，只能猜测合并顺序符合正常人思维，然后才过的。做这个实验，很多时候要靠猜测，比如重定位类型，util.h 文件定义为 int 型，文档中虽然说了 relocation type 的类型，却并没有讲代码头文件中有相关定义。还有我感觉文档没有讲清楚实验的流程，多个小测验是相通的，test0 中就说明了多个目标文件的合并问题，在这里写完相关代码后，再编写完 test3，test4 和 test5 我实验要求都没看，系统就判定我过了。我感觉这个实验可以把实验细节讲详细些，实验难度可以提升一下。
感谢你的反馈！你的意见对这个新实验很宝贵。
对你提出的问题我稍微做一点澄清：
感觉这次实验难度某种意义上很简单，因为实验流程很简单，代码量也很小
它在设计上的本意如此。想象一下，如果把 util.cc 去掉呢？如果在此过程中我们不调用ld，全部事情都自己做呢？
具体实验中还有 bug，比如 test1 的重定位类型没有 R-X86-64-PC32，与文档描述不符
test1 似乎本就不该有 R_X86_64_PC32？之前的版本里确实会生成它，不过这个 bug 已经修复了。如果你在本地还能看到，请 pull 后重新编译。
还有有关多个目标文件合并顺序的问题，文档里也没有细讲
你说得对，这里应该在文档里进行补充。
比如重定位类型，util.h 文件定义为 int 型，文档中虽然说了 relocation type 的类型，却并没有讲代码头文件中有相关定义
大家在代码里只需要做类似re.type == R_X86_64_PC32的判断即可，似乎并没有必要知道 R_X86_64_PC32 是在哪里定义的。
test0 中就说明了多个目标文件的合并问题
实际上，直到 test 4，大家才真的需要考虑将多个.o 合并在一起的情况。我们确实可以把“多个目标文件合并后需要调整 offset”放在这里再讲，但考虑到前边一直在讲知识，从连贯性的角度出发，最终还是决定放弃这种“娓娓道来”的讲法，在一开始就把所有需要完成的任务先讲出来，让大家有一个基础的认识。这样的坏处就如你所体验到的，在解题时没有环环相扣的感觉。
test4 和 test5 我实验要求都没看，系统就判定我过了
这个问题我在群里和论坛里也都说了，属于时间仓促下的一个 bug，今年就当是送给大家了。不过就算是这两个测试点有正确的实现，部分同学仍然会觉得简单，因为这个过程确实不太复杂。
最后重复一下我们的初心：纸上得来终觉浅，这个实验的出发点就是为了让大家获得一个上手实践静态链接的机会，从而加深理解。不是为了为难大家。
1 Like
原来是因为 lab 变简单了，我还以为是我变强了