共享库的加载时重定位

本文旨在解释现代操作系统如何实现使用加载时重新定位的共享库。它专注于运行在32位x86上的Linux操作系统，但一般原则也适用于其他操作系统和CPU。

请注意，共享库有许多名称-共享库、共享对象、动态共享对象（DSO）、动态链接库（DLL，如果你来自Windows背景）。为了保持一致性，我将尽量在整个文章中使用“共享库”这一名称。

加载可执行文件

Linux与其他支持虚拟内存的操作系统类似，会将可执行文件加载到固定的内存地址。如果我们检查某个随机可执行文件的ELF头部，我们会看到一个入口点地址：

$ readelf -h /usr/bin/uptime
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  [...] some header fields
  Entry point address:               0x8048470
  [...] some header fields

链接器将这段代码放在这里，告诉操作系统从何处开始执行可执行文件的代码[1]。如果我们使用GDB加载可执行文件并检查地址0x8048470，我们会看到可执行文件的.text段的第一条指令就在那里。

这意味着，当链接器链接可执行文件时，可以完全解析所有内部符号引用（到函数和数据）到固定和最终的位置。链接器会做一些自己的重定位[2]，但最终它产生的输出不包含任何额外的重定位。

真的吗？请注意，我在上一段中强调了“内部”这