本文共 8524 字，大约阅读时间需要 28 分钟。
符号解析是Linux系统导入二进制可执行文件的重要过程，它完成的工作包括将一个符号定位到实际的内存地址，并且要保证可以正确引用这些符号。按解析对象的不同它可以分为变量符号解析和函数符号解析；按解析方式的不同可以分为静态解析和动态解析。
对于静态解析的符号，它们的地址在文件生成时就由link editor（在Linux下通常是ld）已经确定下来了；对于动态解析的符号，他们的地址在程序运行时才由dynamic linker（动态链接器，32位Linux平台下通常是/lib/ld.so.1）确定下来。我们可以这么认为，如果一个符号在共享库中定义，那么当其他可执行文件或共享库引用这个符号时，就需要对它作动态解析。
变量符号的动态解析过程比较简单，系统在载入程序过程中将变量symbol地址存入到GOT（Global Offset Table）中，引用变量symbol时首先计算出ＧＯＴ表的实际地址，然后以它作为基址加上（变量symbol在GOT表中的偏移量）就可以从ＧＯＴ表中取得该symbol的实际地址。下面以SUSE Linux Enterprise Server 8.1 for IBM pSeries为例，主要讲述和演示３２位PowerPC Linux下函数符号的动态解析过程。
在讲述解析过程之前，先介绍一下在解析过程中要用到的基本概念。
1． ELF（Executable and Linkable Format）文件
ELF是Linux缺省采用的可执行文件（包括共享库，object文件）的格式，具体规范参见参考文献［１］、［２］。这里需要提一下的是section这个概念：section是ELF文件中一段互相联系信息，它可以是一段数据，也可以是一段代码。比如可执行代码信息就放在.text section中，被用户初始化的变量会放在.data section中，没有被用户初始化的变量会放在.bss section（bss是below stack segment的缩写）中。还有其他的一些 section： .debug、 .hash、 .symtab、 .dynsym、 .plt、 .rel.plt 等等。 .dynsym（动态符号表）、 .plt（过程链接表）和.rel.plt（重定位表）和我们的话题有关。
2． 符号表（symbol table）
符号表记录了程序中符号的定义信息和引用信息，它是一个结构数组，数组中的每个元素对应一个符号所有的信息。我们可以在glibc的源代码glibc-2.2/elf/elf.h中看到这个结构的c语言定义：
typedef struct{Elf32_Word st_name; /* 符号名 (.string表的索引) */Elf32_Addr st_value; /* 符号值（Symbol value） */Elf32_Word st_size; unsigned char st_info; unsigned char st_other; Elf32_Section st_shndx; } Elf32_Sym; |
对于可执行文件和共享库而言，符号值记录了该符号的内存地址。可执行文件知道运行时刻他们的地址，所以他们内部的引用符号在编译时候就已经确定了；共享库symbol的符号值（symbol value）就要等到共享库被载入到内存中才确定下来。
我们可以用"readelf -s 文件名"来查看elf文件的symbol值，一般会有两个symbol表：.symtab(包含静态符号和动态符号)和.dynsym（仅包含动态符号）表。下面是我自己机器上的一个输出：
cj@bluesky:~/program/GOT> readelf -s test32Symbol table '.dynsym' contains 6 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 10010894 488 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.0 ……………………Symbol table '.symtab' contains 228 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 10000114 0 SECTION LOCAL DEFAULT 1 …………………… |
3．过程链接表（Procedure Linkage Table，PLT）
静态解析函数符号很简单，因为引用是在内部进行的，只要用下面的命令就可实现：
bl resolved_symbol //resolved_symbol是被引用函数的入口点
动态解析符号则不然，由于link editor不能在编译时就确定被引用函数的入口点，所以它只能将控制权交给第三方，再由这个第三方来完成确定被引用函数入口点的任务，这个第三方就是过程链接表。
过程链接表的格式如下：
- PLT表开头的18个字（72字节）为dynamic linker保留
- 如果可执行文件或共享库需要N个.PLTi入口，那么紧跟着这18个字，link editor就会保留3*N个字（12*N字节），开头的2*N个字就是所有的.PLT入口，对于第i个引用符号，它的.PLT入口是（72+（i-1）*8）（1<=i<=N）,剩下的N个字留给dynamic linker使用。 过程链接表虽然存在于文件当中，但它的初始化是由dynamic linker在装载可执行文件和共享库时完成的。下面是一个可能的被初始化的PLT表的内容：
.PLT:.PLTresolve:addis r12,r0,dynamic_linker@haaddi r12,r12,dynamic_linker@l mtctr r12 //到此为此，r12和ctr中是dynamic linker的地址addis r12,r0,symtab_addr@haaddi r12,r12,symtab_addr@lbctr //此时r12中是共享库symbol表的地址.PLTcall:addis r11,r11,.PLTtable@halwz r11,.PLTtable@l(r11)mtctr r11bctr8 个nop指令.PLT1:addi r11,r0,4*0b .PLTresolve. . ..PLTi:addi r11,r0,4*(i-1)b .PLTresolve. . ..PLTN:addi r11,r0,4*(N-1)b .PLTresolve.PLTtable: |
4． Relocation表
Relocation表总是和PLT表紧紧联系在一起，也就是说，PLT表有多少个入口，Relocation表就有多少个入口，他们是一对一的关系。下面是Relocation结构的c语言定义：
typedef struct {Elf32_Addr r_offset; //.PLTi的地址Elf32_Word r_info; //包含symbol index信息} Elf32_Rel; |
在上述过程链接表的例子中r11是Relocation表和PLT表的index，dynamic linker需要r11来找到对应于这次解析的Relocation表的元素，然后得到r_info，由于r_info中包含了symbol index信息，我们就可确定是寻找哪个symbol的地址；得到symbol的地址后还需要r11来确定将这个地址正确重定位到那个PLT入口（r_offset保存了.PLTi的地址）。
当调用一个外部的函数时，它传输控制到PLT 中跟该symbol 相关的那个entry (是在编译时候由link editor完成的)，然后将偏移量（就是Relocation表的index）置入r11，转入到.PLTresolve处执行；.PLTresolve取得dynamic linker的地址，将共享库的symbol表地址赋给r12后调用dynamic linker的解析函数_dl_runtime_resolve；_dl_runtime_resolve会根据r11取得和该PLT entry对应的Relocation entry，然后得到symbol index，结合r12找到该函数符号的载入地址loaded_addr，并从Relocation entry中得到.PLTi的地址，将.PLTi处的命令修改为b loaded_addr，完成该次符号解析。这样以后若还有调用该函数的语句，就会直接跳往loaded_addr。
下面将以程序为例，演示SUSE SLES 8.1 for IBM pSeries是如何动态解析函数符号printf 的。
例子程序Sample.c
1 #include 2 3 int main(int argc, char *argv[]) 4 { 5 printf("Hello, world!\n"); 6 return 0; 7 } |
1．Run gdb：gdb sample
2．反汇编printf符号
(gdb) disassemble printfDump of assembler code for function printf:0x1001089c : .long 0x0……………………..0x100108b4 : .long 0x0End of assembler dump. |
由于sample还没有运行，所以printf函数还没有被载入到内存中，它的.PLTi入口初始为0
3．反汇编main函数
(gdb) disassemble mainDump of assembler code for function main:0x10000448 : stwu r1,-32(r1)……………………..0x10000470 : bl 0x1001089c …………………….. |
4. 设置断点并运行sample
(gdb) b *0x10000470Breakpoint 1 at 0x10000470(gdb) rStarting program: /home/cj/program/GOT/sample Breakpoint 1, 0x10000470 in main ()(gdb) disassemble 0x1001089cDump of assembler code for function printf:0x1001089c : li r11,40x100108a0 : b 0x1001086c <_GLOBAL_OFFSET_TABLE_+48>0x100108a4 : li r11,80x100108a8 : b 0x1001086c <_GLOBAL_OFFSET_TABLE_+48>……………………..End of assembler dump. |
我们发现0x1001089c处的代码已经改变，表明在载入sample程序的过程中ld.so.1已经修改了printf函数的.PLTi入口。r11值为4，即是printf 在relocation表中的index。
5．反汇编0x1001086c
0x1001086c相当于.PLTresolve，它会调用_dl_runtime_resolve来解析符号
(gdb) disassemble 0x1001086cDump of assembler code for function _GLOBAL_OFFSET_TABLE_:……………………..0x1001084c <_GLOBAL_OFFSET_TABLE_+16>: addis r11,r11,40970x10010850 <_GLOBAL_OFFSET_TABLE_+20>: lwz r11,2220(r11)0x10010854 <_GLOBAL_OFFSET_TABLE_+24>: mtctr r110x10010858 <_GLOBAL_OFFSET_TABLE_+28>: bctr0x1001085c <_GLOBAL_OFFSET_TABLE_+32>: .long 0x00x10010860 <_GLOBAL_OFFSET_TABLE_+36>: .long 0x00x10010864 <_GLOBAL_OFFSET_TABLE_+40>: addis r11,r11,-40970x10010868 <_GLOBAL_OFFSET_TABLE_+44>: addi r11,r11,-22200x1001086c <_GLOBAL_OFFSET_TABLE_+48>: rlwinm r12,r11,1,0,300x10010870 <_GLOBAL_OFFSET_TABLE_+52>: add r11,r12,r110x10010874 <_GLOBAL_OFFSET_TABLE_+56>: li r12,-203440x10010878 <_GLOBAL_OFFSET_TABLE_+60>: addis r12,r12,163850x1001087c <_GLOBAL_OFFSET_TABLE_+64>: mtctr r12 //此时ctr中存放_dl_runtime_resolve的地址0x10010880 <_GLOBAL_OFFSET_TABLE_+68>: li r12,229040x10010884 <_GLOBAL_OFFSET_TABLE_+72>: addis r12,r12,16386 //此时r12存放/lib/libc.so.6的symbol表的地址0x10010888 <_GLOBAL_OFFSET_TABLE_+76>: bctr0x1001088c <_GLOBAL_OFFSET_TABLE_+80>: .long 0x00x10010890 <_GLOBAL_OFFSET_TABLE_+84>: .long 0x00x10010894 <__libc_start_main>: b 0xfed8ff0 <__libc_start_main>0x10010898 <__libc_start_main+4>: b 0x1001086c <_GLOBAL_OFFSET_TABLE_+48>0x1001089c : li r11,40x100108a0 : b 0x1001086c <_GLOBAL_OFFSET_TABLE_+48>0x100108a4 : li r11,80x100108a8 : b 0x1001086c <_GLOBAL_OFFSET_TABLE_+48>……………………..End of assembler dump. |
(gdb) b *0x10010888Breakpoint 2 at 0x10010888(gdb) i r ctrctr 0x4000b088 1073787016(gdb) disassemble 0x4000b088Dump of assembler code for function _dl_runtime_resolve:0x4000b088 <_dl_runtime_resolve>: stwu r1,-64(r1)……………………..0x4000b0c4 <_dl_runtime_resolve+60>: stw r0,8(r1)0x4000b0c8 <_dl_runtime_resolve+64>: bl 0x4000ad3c 0x4000b0cc <_dl_runtime_resolve+68>: mtctr r3……………………..0x4000b104 <_dl_runtime_resolve+124>: addi r1,r1,640x4000b108 <_dl_runtime_resolve+128>: bctrEnd of assembler dump. |
我们可以通过查看glibc的源代码来看_dl_runtime_resolve是如何得到symbol的地址值的，它在文件glibc-2.2/sysdeps/powerpc/dl-machine.h中定义。
(gdb) niHello, world!0x10000474 in main () |
6．再次反汇编0x1001089c
(gdb) disassemble 0x1001089cDump of assembler code for function printf:0x1001089c : b 0xff0ec9c 0x100108a0 : b 0x1001086c <_GLOBAL_OFFSET_TABLE_+48>……………………..End of assembler dump. |
对比上述第四个步骤，0x1001089c <printf>: li r11,4已经被修正为 0x1001089c <printf>: b 0xff0ec9c <printf>了，以后若还有调用printf的语句，控制权就会直接转到0xff0ec9c，0xff0ec9c是printf函数的真正入口点。
从以上的分析和演示过程中我们可以看到32 位PowerPC的函数符号动态解析和i386 Linux体系结构的函数符号动态过程大体一致，它们都是先跳转到对应的.PLTi入口，保存Relocation偏移量，然后跳转到_dl_runtime_resolve，由它来完成寻找函数符号的任务。不同的地方是：1. 由于b命令的限制（b 命令可能第一次跳转不到函数入口点），所以对于不能一次跳到函数入口点的情况就需要两次跳转（先将跳转地址存到.PLTtable+4*(i-1)，然后将.PLTi处的b .PLTresolve修改为b .PLTcall，由它用bctr命令来完成跳转到函数入口点的任务）; 2. i386 Linux将跳转地址存入到GOT[x+i]中，PowerPC则根本不使用GOT表，而是通过直接修改.PLTi处的代码来达到相同的功能。
１． ELF1.1规范中文版
２． ELF1.2规范英文版 Tool Interface Standard (TIS) Executable and Linking Format Specification
３． SYSTEM V APPLICATION BINARY INTERFACE PowerPC Processor Supplement
转载地址：http://xbhvi.baihongyu.com/