引言

这章主要讲的是将两个目标文件链接起来的过程，核心内容：静态链接

这一节主要使用下面两个源代码”a.c“和”b.c“作为例子讲解：

/* a.c */
extern int shared;int main() {int a = 100;swap( &a, &shared );
}/* b.c */
int shared = 1;void swap( int* a , int* b ) {*a ^= *b ^= *a ^= *b;
}

假设程序只有这两个模块，使用gcc将两个模块编译成.o目标文件：

$ gcc -c a.c b.c -m32

从代码中可以看到，b.c定义了两个全局符号，一个是变量”shared“，另外一个是函数”swap“。a.c中定义了一个全局符号函数”main“。模块a.c中引用到了b.c中的”swap“和”shared“，接下来要做的就是把a.o和b.o两个目标文件链接在一起，并最终形成一个可执行文件”ab“

一、拆迁分房子啦——空间与地址分配

在链接过程中产生了一个问题：对于多个输入目标文件，链接器如何将他们的各个段合并到输出文件？或者说输出文件中的空间如何分配给输入文件？

1、老大住一楼，老二住二楼

一个最简单的方案就是将输入的目标文件按照次序叠加起来（按序叠加）：
但是这种方法存在一个问题，输出文件将会有很多零散的段。比如规模稍大的应用程序可能会有数百个目标文件，如果每个目标文件都分别由.text段、.data段、.bss段，那最后的输出文件将会有成千上百个零散的段。这样做很浪费空间，每个段都需要有一定的地址和空间对齐要求。所以并不是一个很好的解决方法。

2、男的住一起，女的住一起

一个更实际的方法是将相同性质的段合并到一起（相似段合并）：
虽然.bss段在目标文件和可执行文件中并不占用文件的空间，但在装载时占用地址空间。所以链接器在合并各个段的时候也会将.bss合并，并且分配虚拟空间。我们一直讲的空间分配起始只关注与虚拟空间的分配。

现在的链接器空间分配的策略都采用相似段合并的方法，使用这种方法的链接器采用的是两部链接（Two-pass Linking）的方法：

• 第一步：空间地址分配 扫描所有的输入目标文件，并且获得各个段的长度、属性和位置，并将输入目标文件中的符号表中所有的符号定义和符号引用收集起来，统一放到一个全局符号表中。这一步中，链接器将能够获得所有输入目标文件的段长度，并将其合并，计算出输出文件中各个段合并后的长度与位置，并建立映射关系。
• 第二步：符号解析与重定位 使用上一步中收集到的所有信息，读取输入文件中段的数据、重定位信息，并且进行符号解析与重定位、调整代码中的地址等。

Linux下，ELF文件默认从地址0x08048000开始分配，书中有a.o和b.o链接的例子，但是我的ld 命令不好使，没弄出来。。。。

3、符号地址的确定

在第一步扫描和空间分配阶段，链接器按照前面的方法进行分配，这个时候输入文件中的各个段在链接后的虚拟地址就已经确定了，比如.text段起始地址为0x08048094，.data段的起始地址为0x08049108。

在完成上一步之后，链接器开始计算各个符号的虚拟地址。因为各个符号在段内的相对地址是固定的，比如此时”main“、”shared“和”swap“的地址已经确定，但是链接器还需要给每个符号加上偏移量。

为什么要加上偏移量？举个栗子：假设a.o中的main函数相对于a.o的.text段的偏移是X，但是经过链接合并后a.o的.text段位于虚拟地址0x08048094，那么main的地址应该是0x08048094+X。

二、符号解析与重定位

1、重定位

在分析符号解析和重定位之前，首先看一下a.o里面是怎么使用两个外部符号的，就是在a.c的源程序里面使用了”shared“变量和”swap“函数。当源码”a.c“在被编译成目标文件时，编译器并不知道”shared“和”swap“的地址，因为他们定义在其他目标文件中。所以这时候有两种情况：

• 当使用mov 外部变量；esp指令调用时：函数地址会被表示成00 00 00 00。因为这个时候a.c还不知道外部变量地址是多少，所以空出四位空间进行地址预留。
• 当使用call 外部函数地址时：外部函数地址会表示成fc ff ff ff（小端序），他其实是-4的补码形式，-4相对的是call指令的下一条指令的偏移，因为依然还是不知道外部函数地址是多少，所以找了一个已知的指令地址作为基地址，往前空出四位空间进行地址预留。

2、重定位表

在ELF文件中，有一个叫重定位表（Relocation Table）的结构专门用来保存这些重定位相关的信息，在ELF文件中往往是一个或多个段。对于每个要被重定位的ELF段都有一个对应的重定位表，而一个重定位表往往就是ELF文件中的一个段，所以其实重定位表也可以叫重定位段，也可以统称为重定位表。

每个要被重定位的地方叫一个重定位入口（Relocation Entry），重定位入口的偏移（Offset）表示该入口在要被重定位的段中的位置。

对于32位的Intel x86系列处理器来说，重定位表的结构是一个Elf32_Rel结构的数组，每个数组元素对应一个重定位入口：

typedef struct {Elf32_Addr r_offset;Elf32_Word r_info;
} Elf32_Rel;

成员	含义
r_offset	重定位入口的偏移。对于可重定位文件来说，这个值是该重定位入口所要修正的位置的第一个字节相对于段起始的偏移；对于可执行文件或共享对象文件来说，这个值是该重定位入口所要修正的位置的第一个字节的虚拟地址
r_info	冲行为入口的类型和符号，这个成员的低8位表示重定位入口的类型，高24位表示重定位入口的符号在符号表中的下标 因为各种处理器的指令格式不一样，所以重定位所修正的指令地址格式也不一样，每种处理器都有自己一套重定位入口的类型，对于可执行文件和共享目标文件来说，他们的重定位入口是动态链接类型的

3、符号解析

在重定位的过程中，每个重定位的入口都是对一个符号的引用，那么当链接器需要对某个符号的引用进行重定位时，他就要确定这个符号的目标地址。这个时候链接器就会去找所有输入目标文件的符号表组成的全局符号表，找到相应的符号后进行重定位。在连接器扫描完所有输入目标文件后，所有未定义的符号都应该能够在全局符号表中找到，否则链接器会报符号位定义错误

4、指令修正方式

直至2006年为止，Intel X86系列CPU的jimp指令有11中寻址模式；call指令有10种；mov指令有34种，这些寻址方式有如下几方面的区别：

• 近址寻址或远址寻址
• 绝对寻址或相对寻址
• 寻址长度为8位、16位、32位、或64位。但是对于32位x86平台下的ELF文件的重定位入口修正的指令寻址只有两种：
  • 绝对近址32位寻址
  • 相对近址32位寻址

这两种重定位方式指令修正方式每个被修正的位置的长度都为32位，即4个字节。而且都是近址寻址，不用考虑段间远址寻址。唯一区别就是相对寻址和绝对寻址。重定位入口的r_info成员低8位表示重定位入口类型：

宏定义	值	重定位修正方法
R_386_32	1	绝对修正S + A
R_386_PC32	2	相对寻址修正S + A - P

A = 保存在被修正位置的值
P = 被修正的位置（相对于段开始的偏移量或者虚拟地址），该值可通过r_offset计算得到
S = 符号的实际地址，即由r_info的高24位指定的符号的实际地址

对照前面a.o的重定位信息，第一个重定位入口是对swap符号的引用，类型为R_386_PC32，是一条相对位移调用指令，根据原文例子得出偏移为0x26

而shared是R_386_32类型的，是一条传输指令的源，该传输指令的源是一个立即数，即shared的绝对地址，根据原文例子得出偏移为0x18

这两种重定位入口分别代表了两种不同的重定位地址修正方式。

假设a.o和b.o链接成最终可执行文件后，main函数的虚拟地址为0x1000，swap函数的虚拟地址为0x2000，shared变量的虚拟地址为0x3000，接下来我们模拟一下修正这两个重定位入口：

绝对寻址修正

先看a.o的第一个重定位入口，即偏移为0x18这条mov指令的修正，它的修正方式是R_386_32，即绝对地址修正。对于这个重定位入口，他修正后的结果应该是S + A

• S是符号shared的实际地址，即0x3000
• A是被修正位置的值，即0x00000000

所以左后这个重定位入口修正后的地址为：0x3000 + 0x00000000 = 0x3000

相对寻址修正

再看第二个重定位入口，即偏移为0x26的call指令的修正，它的指令修正方式为R_386_PC32，即相对寻址修正，它修正后的结果应该是S + A - P

• S是符号swap的实际地址，即0x2000
• A是被修正位置的值，即0xFFFFFFFC（-4）
• P为被修正的位置，当链接成可执行文件时，这个值应该是被修正位置的虚拟地址，即0x1000 + 0x27
  
  所以最后重定位入口修正后的地址为：0x2000 + （-4）- （0x1000 + 0x27）= 0xFD5。
  
  这条相对位移调用指令调用的地址是该指令下一条指令的起始地址加上偏移量，即0x102b + 0xfd5 = 0x2000

这两个例子可以看出来，绝对寻址修正和相对寻址修正的区别就是绝对寻址修正后的地址为该符号地址，相对寻址修正后的地址为符号距离被修正位置的地址差

三、静态库链接

程序如果需要进行输入输出交互，那么就要用到操作系统提供的应用程序编程接口（API ，Application Programming Interface），但是API不能直接通过代码进行调用，需要通过静态库来实现调用

起始静态库可以看成一组目标文件的集合，就像很多目标文件经过压缩打包后形成的一个文件，在Linux中最常用的C语言静态库libc位于/usr/lib/libc.a，属于glibc项目的一部分。

glibc本身是C语言开发的，所以会有很多C语言源代码，编译完成后有同样数量的目标文件。用户使用这么多零散的文件会非常费劲，那么就是用”ar“压缩程序将这些目标文件压缩到一起，并对其进行编号和索引，以便于查找和检索，这就形成了libc.a的静态库

那么静态库是怎么链接的呢，拿helloworld程序举例，程序中会使用到printf函数，那么很显然printf函数并不在原有的源代码当中，它在静态库中，这个时候链接器就派上大用场了，他会自动寻找所需要的符号及他们在静态库中的目标文件，再讲这些目标文件从”libc.a“中”解压“出来，最终将他们链接在一起成为一个可执行文件。理论上可以认为将”hello.o“和”libc.a“链接起来：
这些就是个人认为在做pwn题时候可能会用到的东西，尤其是在重定位表那块，在做高级栈溢出的时候会用到，希望对你会有帮助😜