静态链接

﹏ヽ暗。殇╰゛Y 2023-07-12 11:40 68阅读 0赞

## 静态链接 ##

下面以这两个程序进行静态链接演示

// a.c
    extern int shared;
    
    int main()
    { 
    	int a = 100;
    	swap(&a, &shared);
    	return 0;
    }

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

编译一下

gcc -fno-stack-protector -m32 -c a.c b.c

对于链接器来说，整个链接的过程就是将几个输入的目标文件加工后合并成功一个输出文件。

第一个问题就是：对于多个输入目标文件，链接器如何将它们的各个段合并到输出文件？

答案是将相同性质的段合并到一起，比如将所有输入文件的.text合并到输出文件的.text段，接着是.data段，.bss段等

.bss段在目标文件和可执行文件中并不占用文件的空间，但是它在装载时占用地址空间。

所以链接器在合并各个段的同是，也将.bss合并，并且分配虚拟空间。

对于 链接器为目标文件分配地址和空间 这句话中的 地址和空间 其中有两个含义

第一个是在输出的可执行文件中的空间，第二个是装载后的虚拟地址中的虚拟地址空间

对于有实际数据的段 ，比如.text和.data来说，它们在文件中和虚拟地址中都要分配空间，因为它们在这两者中都存在，而对于.bss这样的段来说，分配空间的意义只局限于虚拟地址空间，因为它在文件中并没有内存。

事实上，这里谈到的空间分配至关注与虚拟地址空间的分配，因为这个关系到链接器后面的关于地址计算的步骤，而可执行文件本身的空间分配与链接过程关系并不是很大。

## 链接的过程 ##

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

ld -m elf_i386 a.o b.o -e main -o ab

objdump -h a.o

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg_size_16_color_FFFFFF_t_70_pic_center]

VMA表示**Virtual Memory Address**，即虚拟地址，LMA表示**Load Memory Address**，即加载地址，正常情况下这两个值应该是一样的。

链接后的程序所使用的地址已经是程序在进程中的虚拟地址，即我们关心各个段中的VMW和Size，而忽略文件偏移File off。

可以看到，在链接之前，目标文件中的所有短的VMA都是0，因为虚拟空间还没有被分配，所以默认它们都为0。

等到链接以后，可执行文件ab中的各个段都被分配到了响应的虚拟地址。

objdump -h ab

这涉及到操作系统的进程虚拟地址空间的分配规则，在Linux下，ELF可执行文件默认从地址0x08048094开始分配。

## 符号地址的确定 ##

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

当前面一步完成后，链接器开始计算各个符号的虚拟地址。因为各个符号在段内的相对位置是固定的，所以这时候起始main、shared和swap的地址也已经确定了，只不过链接器须要给每个符号加上一个偏移量，使它们能够调整到正确的虚拟地址。

## 符号解析与重定位 ##

在完成空间和地址的分配以后，链接器就进入了符号解析与重定位的步骤，这也是静态链接的核心内容。

我们知道在程序的代码里使用的都是虚拟地址，在这里也可以看到main的起始地址为0，这是因为在为进行空间分配之前，目标文件代码段中的起始地址以0x0开始，等到空间分配完成后，各个函数才会确定自己在虚拟地址空间中的位置。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg_size_16_color_FFFFFF_t_70_pic_center 2]

当源代码a.c被编译成目标文件时，编译器并不知道shared和swap的地址，因为它们定义在其他目标文件中。所以编译器就暂时把地址0看作是shared的地址。

另一条是`call`指令调用`swap`函数，`0xE8`是操作码，这条指令是一条**近址相对位移调用指令**，后面的4个字节就是被调用函数的相对于调用指令的下一条指令的偏移量。

在没有重定位之前，相对便宜被设置为`0xFFFFFFFC（小端）`，它是常量`-4的补码`形式

紧跟在这条call指令后面的那条指令为`add`指令，add指令的地址为`0x38`,而相对于add指令偏移为-4的地址及`0x38-4=0x34`。所以这条call指令的实际调用地址为`0x34`。

我们可以看到0x34存放的实际上并不是swap函数的地址，和前面shared一样，`0xFFFFFFFC`只是一个临时的假地址，因为在编译时，编译器并不知道swap的真正地址。

编译器把这两条指令的地址部分暂时用地址`0x00000000`和`0xFFFFFFFC`代替，把真正的地址计算工作留给了链接器。

链接器在完成地址和空间分配之后就已经可以确定所有符号的虚拟地址了，那么链接器就可以根据符号的地址对每个需要重定位的指令进行低位修正。

下面我们来看一下ab的代码段，可以看到main函数的两个重定位入口都已经被修正到正确的位置：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg_size_16_color_FFFFFF_t_70_pic_center 3]  
经过修正后，shared和swap的地址分别为`0x804a00c`和`0x80480e2`

关于shared很好理解，因为shared变量的地址的就是`0x804a00c`

而对于swap，就不太一样，前面说过，这个call指令是一条**近址相对位移调用指令**它后面跟的是调用指令的下一条指令的偏移量，call指令的下一条指令是add，它的地址是  
`0x080480cc`,所以相对于add指令偏移量为`0x00000016`的地址为`0x080480cc+0x16=0x80480e2`,即刚好是swap函数的地址`0x80480e2`！！

## 重定位表 ##

那么链接器是怎么知道哪些指令是需要调整的呢？而在上面的例子中mov指令和call指令的调整方式就有所不同，事实上在ELF文件中，有一个叫做**重定位表的结构**专门用来保存这些与重定位相关的信息。

对于可重定位的ELF文件来说，它必须包含有**重定位表**，用来描述如何修改相应的段里的内容。  
**一个重定位表往往就是ELF文件中的一个段**，所以其实重定位表也可以叫做重定位段，我们一般称为重定位表。

比如代码段.text如果有要被重定位的地方，那么会有一个相对应交.rel.text的段保存了代码段的重定位表  
同样，如果代码段.data有要被重定位的地方，就会有一个相对应交.rel.data的段保存数据段的重定位表。

我们可以通过

objdump -r a.o

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg_size_16_color_FFFFFF_t_70_pic_center 4]

用来查看a.o里面要重定位的地方，即a.o所有引用外部符号的地址。  
每个要被重定位的地方叫做一个重定位入口。

重定位入口的便宜Offset表示该入口在要被重定位的段中的位置`RELOCATION RECORDS FOR [.text]` 表示这个重定位表是代码段的重定位表，所以偏移表示代码段中需被调整的位置，对比前面就可知道这里`0x28`和`0x34`就是代码段中mov指令和call指令的地址部分。

## 符号解析 ##

当我们直接使用ld来链接a.o，而不将b.o作为输入，链接器就会发现shared和swap两个符号没有被定义，没有办法完成链接工作  
![在这里插入图片描述][20200308194432196.png_pic_center]  
这也是我们在编写程序过程中最常见的问题，就是链接时符号未定义，导致这个问题的原因很多，通常是缺少某个库文件，或者我们写库文件的路径不正确或符号的声明与定义不一样。

重定位的过程也伴随着符号的解析过程，每个目标文件都可能定义一些符号，也可能引用到定义在其他目标文件的符号。每个重定位的入口都是对一个符号的引用，那么当链接器要对某个符号的引用进行重定位时，就要确定这个符号的目标地址。这时候链接器就会去查找由所有输入目标文件的符号表组成的全局符号表，找到相应的符号进行重定位。

readelf -s a.o

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg_size_16_color_FFFFFF_t_70_pic_center 5]  
**UND**即**undefined** 未定义类型。  
这种未定义的符号都是因为该目标文件中有关于它们的重定位项。所以在链接器扫描完所有的输入目标文件之后，所有这些未定义的符号都应该能够在全局符号表中找到，否则链接器留报符号未定义错误。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20200308201858315.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20200308202029904.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20200308133512209.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg_size_16_color_FFFFFF_t_70_pic_center 3]: https://img-blog.csdnimg.cn/20200308193656378.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg_size_16_color_FFFFFF_t_70_pic_center 4]: https://img-blog.csdnimg.cn/20200308194235983.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg==,size_16,color_FFFFFF,t_70#pic_center
[20200308194432196.png_pic_center]: https://img-blog.csdnimg.cn/20200308194432196.png#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg_size_16_color_FFFFFF_t_70_pic_center 5]: https://img-blog.csdnimg.cn/20200308194526880.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgzMzY0Mg==,size_16,color_FFFFFF,t_70#pic_center