动态链接库可以跨平台吗（动态链接的相关结构）

在了解了共享对象的绝对地址的引用问题后，我们基本上对动态链接的原理有了初步的了解，接下来的问题是整个动态链接具体的实现过程了。动态链接在不同的系统上有不同的实现方式。ELF的动态链接的实现方式会比PE的简单一点，在这里我们先介绍ELF的动态链接过程在LINUX下的实现，最后我们会专门的章节中介绍PE在Windows下的动态链接过程和它们的区别

我们在前面的章节已经看到,动态链接情况下,可执行文件的装载与静态链接情况基本样。首先操作系统会读取可执行文件的头部检查文件的合法性,然后从头部中的“ Program Header”中读取每个“Segment”的虚拟地址、文件地址和属性,并将它们映射到进程虚拟空间的相应位置,这些步骤跟前面的静态链接情况下的装载基本无异。在静态链接情况下,操作系统接着就可以把控制权转交给可执行文件的入口地址,然后程序开始执行,一切看起来非常直观。

但是在动态链接情况下,操作系统还不能在装载完可执行文件之后就把控制权交给可执行文件,因为我们知道可执行文件依赖于很多共享对象。这时候,可执行文件里对于很多外部符号的引用还处于无效地址的状态,即还没有跟相应的共享对象中的实际位置链接起来。所以在映射完可执行文件之后,操作系统会先启动个动态链接器( dynamic Linker)

在 linux下,动态链接器ld.so实际上是一个共享对象,操作系统同样通过映射的方式将它加载到进程的地址空间中。操作系统在加载完动态链接器之后,就将控制权交给动态链接器的入口地址(与可执行文件一样,共享对象也有入口地址)。当动态链接器得到控制权之后,它开始执行一系列自身的初始化操作,然后根据当前的环境参数,开始对可执行文件进行动态链接工作。当所有动态链接工作完成以后,动态链接器会将控制权转交到可执行文件的入口地址,程序开始正式执行

1. ".interp"段

那么系统中哪个才是动态链接器呢,它的位置由谁决定?是不是所有的*NX系统的动态链接器都位于 /lib/ld.so呢?实际上,动态链接器的位置既不是由系统配置指定,也不是由环境参数决定,而是由ELF可执行文件决定。在动态链接的ELF可执行文件中,有一个专门的段叫做“ Interp”段(“ Interp”是“ Interpreter”(解释器)的缩写)。如果我们使用 objdump工具来查看,可以看到“ .interp”内容:

动态链接库可以跨平台吗（动态链接的相关结构）(1)

".interp"的内容很简单，里面保存的就是一个字符串，这个字符串就是可执行的所需要的动态链接器的路径。在LINUX下，可执行文件所需要的动态链接器的路径几乎都是 “/lib/ld-linux.so.2”，其他的*.nix操作系统可能会有不同路径。我们在后面还会介绍到各种环境下的动态链接器的路径。在LINUX系统中，/lib/ld-linux.so.2通常是一个软链接，比如在我的机器中，它指向/lib/ld-linux.so.2，这个才是真正的动态链接器，在linux中，操作系统在对可执行文件所需要的相应动态连接器，即“.interp”段指定的路径的共享对象；

动态链接器在linux下是Glibc的一部分，也就是属于系统库级别的，它的版本号往往跟系统的Glibc库版本号是一样的，比如我的系统中安装的是glibc 2.6.1，那么相应的动态链接库就是/lib/ld-2.6.1.so。当系统中的Glibc库更新或者安装其他版本的时候，/lib/ld-linux.so.2 这个软链接就会指向新的动态链接器，而可执行文件本身不需要修改 ".interp" 中的动态链接器路径来适应系统的升级

我们往往可以用这个命令来查看一个可执行文件所需要的动态链接器的路径，在linux下，往往是这个结果：

readelf -l a.out | grep interpreter [Requeseting program interpreter: /lib/ld-linux.so.2]

而当我们在FreeBSD 4.6.2 下执行这个命令时，结果是：

readelf -l a.out | grep interpreter

64 位的linux下的可执行文件是：

readelf -l a.out | grep interpreter

2. “.dynamic”段

类似于“.interp”这样的段，ELF中还有几个段也是专门用于动态链接的，比如 ".dynamic" 段和 ".dynsym"段等。要了解动态链接器如何完成链接过程，跟前面一样，从了解ELF文件中跟动态链接相关的结构入手将会是一个很好的途径。ELF文件中跟动态链接相关的段有好几个，相互之间的关系也比较复杂，我们先从 ".dynamic" 段入手

动态链接ELF中最重要的结构应该是“ .dynamic”段,这个段里面保存了动态链接器所需要的基本信息,比如依赖于哪些共享对象、动态链接符号表的位置、动态链接重定位表的位置、共享对象初始化代码的地址等。“ .dynamic”段的结构很经典,就是我们已经碰到过的ELF中眼熟的结构数组,结构定义在“elf.h”中:

typedef struct { Elf32_Sword d_tag; union { Elf32_Word d_val; Elf32_Addr d_ptr; } d_un; } Elf32_Dyn;

Elf32_Dyn 结构由一个类型值加上一个附加的数值或指针，对于不同类型，后面附加的数值或者指针有着不同含义。我们这里列举几个比较常见的类型值（这些值都是定义在“elf.h”里面的宏），如表7-2所示：

动态链接库可以跨平台吗（动态链接的相关结构）(2)

表7-2中只列出了一部分定义，还有一些不太常用的定义我们就暂且忽略，具体可以参考LSB手册和elf.h的定义。从上面给出的定义来看，“.dynamic”段里面保存的信息有点像elf文件头，只是我们看到的elf文件头中保存的是静态链接时的相关信息，比如静态链接时使用到的符号表、重定位表等，这里换成了动态链接下所使用的相应信息了。所以，“.dynamic”段可以看成动态链接下的ELF文件的“文件头”。使用readelf工具可以查看 ".dynamic" 段的内容

$ readelf -d lib.so

动态链接库可以跨平台吗（动态链接的相关结构）(3)

动态链接库可以跨平台吗（动态链接的相关结构）(4)

另外linux还提供了一个命令用来查看一个程序主模块或一个共享库依赖于哪些共享库：

动态链接库可以跨平台吗（动态链接的相关结构）(5)

动态符号表

为了完成动态链接,最关键的还是所依赖的符号和相关文件的信息。我们知道在静态链接中,有一个专门的段叫做符号表“.symtab”( Symbol Table),里面保存了所有关于该目标文件的符号的定义和引用。动态链接的符号表示实际上它跟静态链接十分相似,比如前面例子中的 Program1程序依赖于 Lib.so,引用到了里面的 foobar()函数。那么对于 Program1来说,我们往往称 ProgramI导入( Import)了 foobar函数, foobar是 Program1的导入函数(import Function):而站在Lib.so的角度来看,它实际上定义了 foobar函数,并且提供给其他模块使用,我们往往称Lib.so导出( Export)了 foobar函数, foobar是Lbso的导出函数(Export Function)。把这种导入导出关系放到静态链接的情形下,我们可以把它们看作普通的函数定义和引用。

为了表示动态链接这些模块之间的符号导入导出关系，ELF专门有一个叫做动态符号表（Dynamic symbol table）的段用来保存这些信息，这个段的段名通常叫做“.dynsym”(Dynamic Symbol)。与 “.sysmtab”不同的是，".dynsym" 只保存了与动态链接相关的符号，对于那些模块内部的符号，比如模块私有变量则不保存。很多时候动态链接的模块同时拥有“.dynsym” 和 ".sysmtab"中往往保存了所有符号，包括 “.dynsym” 中的符号

与 “.sysmtab” 类似，动态符号表也需要一些辅助的表，比如用于保存符号名的字符串表。静态链接的时候叫做符号字符串“.strtab” (Striing Table)，在这里就是动态符号字符串表“.dynstr” (Dynamic String Table)；由于动态链接下，我们需要在程序运行时查找符号，为了加快符号的查找过程，往往还有辅助的符号哈希表（“.hash”）。我们可以用readelf工具来查看elf文件的动态符号表及哈希表：

readelf -sD lib.so

动态链接库可以跨平台吗（动态链接的相关结构）(6)

动态链接符号表的结构与静态链接的符号表几乎一样，我们可以简单的将导入韩式看作是对其他目标文件中函数的引用：把导出函数看作是在本目标文件定义的函数就可以了；

3. 动态链接重定位表

共享对象需要重定位的主要原因是导入符号的存在。在动态链接下，无论是可执行文件或共享对象，一旦它依赖于其他共享对象，也就是说有导入的符号时，那么它的代码或数据中就会有对于导入符号的引用。在编译时这些导入符号的地址未知，在静态链接中，这些未知的地址引用在最终链接时被修正。但是在动态链接中，导入符号的地址在运行时才确定，所以需要在运行时将这些导入符号的引用修正，即需要重定位；

我们在前面地址无关章节中也提到过，动态链接的可执行文件使用的是PIC方法，但这不能改变它需要重定位的本质。对于动态链接来说，如果一个共享对象不是以PIC模式编译的，那么毫无疑问，它是需要在装载时被重定位的：如果一个共享对象是PIC模式编译的，那么它还需要再装载时进行重定位吗？是的，PIC的共享对象也是需要重定位的；

对于使用PIC技术的可执行文件或共享对象来说,虽然它们的代码段不需要重定位(因为地址无关),但是数据段还包含了绝对地址的引用,因为代码段中绝对地址相关的部分被分离了出来,变成了GOT,而GOT实际上是数据段的一部分。除了GOT以外,数据段还可能包含绝对地址引用,我们在前面的章节中已经举例过了。

动态链接重定位的相关结构

共享对象的重定位与我们在前面“静态链接”中分析过的目标文件的重定位十分类似,唯一有区别的是目标文件的重定位是在静态链接时完成的,而共享对象的重定位是在装载时完成的。在静态链接中,目标文件里面包含有专门用于表示重定位信息的重定位表,比如“rel.text”表示是代码段的重定位表,“rel.data”是数据段的重定位表。

动态链接的文件中,也有类似的重定位表分别叫做“ .rel.dyn”和“.rel. plt”,它们分别相当于“.rel.text”和“.rel.data”“.rel .dyn”实际上是对数据引用的修正,它所修正的位置位于“.got”以及数据段;而“ .rel.plt”是对函数引用的修正,它所修正的位置位于“.got.plt”。我们可以使用 readelf来查看一个动态链接的文件的重定位表

动态链接库可以跨平台吗（动态链接的相关结构）(7)

可以看到Lib.c中两个导入函数“printf” 和“sleep” 从“.rel.plt”到了“.rel.dyn”，并且类型也从R_386_JUMP_SLOT变成了R_386_PC32

而R_386_RELATIVE类型多出了一个偏移为0x0000042c的入口，这个入口是什么呢？通过对Lib.so 的反汇编可以知道，这个入口用来修正给printf的第一个参数，即我们的字符串常量“Printing from Lib.so %d\n”的地址。为什么这个字符串常量的地址在PIC时不需要重定位而在非PIC时需要重定位呢？很明显，PIC时，这个字符串可以看做是普通的全局变量，它的地址是可以通过PIC中的相对当前指令的位置加上一个固定偏移计算出来的：而在非PIC中，代码段不再使用这种相对于当前指令的PIC方法，而是采用绝对地址寻址，所以它需要重定位；

动态链接时进程堆栈初始化信息

站在动态链接器的角度看,当操作系统把控制权交给它的时候,它将开始做链接丁作,那么至少它需要知道关于可执行文件和本进程的一些信息,比如可执行文件有几个段(“ Segment”)、每个段的属性、程序的入口地址(因为动态链接器到时候需要把控制权交给可执行文件)等。这些信息往往由操作系统传递给动态链接器,保存在进程的堆栈里面。我们在前面提到过,进程初始化的时候,堆栈里面保存了关于进程执行环境和命令行参数等信息。事实上,堆栈里面还保存了动态链接器所需要的一些辅助信息数组( Auxiliary Vector)。辅助信息的格式也是一个结构数组,它的结构被定义在“elf.h”

typedf struct { uint32_t a_type; union { uint32_t a_val; } a_un; } Elf32_auxv_t;

是不是已经对这种结构很熟悉了？没错，跟前面的“.dynamic”段里面的结构如出一辙。先是一个32位类型的值，后面是一个32位的数值部分，你很可能很奇怪为什么要用一个union把后面的32位数值包装起来，事实上，这个union没啥用，只是历史遗留而已，可以当做不存在。我们摘录几个比较重要的类型值，这几个类型值都是比较常见的，而且是动态链接器在启动时所需要的，如表7-3所示：

动态链接库可以跨平台吗（动态链接的相关结构）(8)