PowerPC上ELF可执行文件的符号解析(一).docVIP

PowerPC上ELF可执行文件的符号解析(一)一． 前言符号解析是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: 0 NOTYPE LOCAL DEFAULT UND 1: 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: 0 NOTYPE LOCAL DEFAULT UND 1: 0 SECTIO