转自：http://www.ibm.com/developerworks/cn/linux/l-dynlink/index.html 一个程序要想在内存中运行，除了编译之外还要经过链接和装入这两个步骤。从程序员的角度来看，引入这两个步骤带来的好处就是可以直接在程序中使用 printf和errno这种有意义的函数名和变量名，而不用明确指明printf和errno在标准C库中的地址。当然，为了将程序员从早期直接使用地址编程的梦魇中解救出来，编译器和汇编器在这当中做出了革命性的贡献。编译器和汇编器的出现使得程序员可以在程序中使用更具意义的符号来为函数和变量命名，这样使得程序在正确性和可读性等方面都得到了极大的提高。但是随着C语言这种支持分别编译的程序设计语言的流行，一个完整的程序往往被分割为若干个独立的部分并行开发，而各个模块间通过函数接口或全局变量进行通讯。这就带来了一个问题，编译器只能在一个模块内部完成符号名到地址的转换工作，不同模块间的符号解析由谁来做呢？比如前面所举的例子，调用printf的用户程序和实现了printf的标准C库显然就是两个不同的模块。实际上，这个工作是由链接器来完成的。 为了解决不同模块间的链接问题，链接器主要有两个工作要做――符号解析和重定位： 符号解析：当一个模块使用了在该模块中没有定义过的函数或全局变量时，编译器生成的符号表会标记出所有这样的函数或全局变量，而链接器的责任就是要到别的模块中去查找它们的定义，如果没有找到合适的定义或者找到的合适的定义不唯一，符号解析都无法正常完成。 重定位：编译器在编译生成目标文件时，通常都使用从零开始的相对地址。然而，在链接过程中，链接器将从一个指定的地址开始，根据输入的目标文件的顺序以段为单位将它们一个接一个的拼装起来。除了目标文件的拼装之外，在重定位的过程中还完成了两个任务：一是生成最终的符号表；二是对代码段中的某些位置进行修改，所有需要修改的位置都由编译器生成的重定位表指出。 举个简单的例子，上面的概念对读者来说就一目了然了。假如我们有一个程序由两部分构成，m.c中的main函数调用f.c中实现的函数sum： /* m.c */ int i = 1; int j = 2; extern int sum(); void main() { int s; s = sum(i, j); /* f.c */ int sum(int i, int j) { return i + j; } 在Linux用gcc分别将两段源程序编译成目标文件： $ gcc -c m.c $ gcc -c f.c 我们通过objdump来看看在编译过程中生成的符号表和重定位表： $ objdump -x m.o …… SYMBOL TABLE: …… 00000000 g O .data 00000004 i 00000004 g O .data 00000004 j 00000000 g F .text 00000021 main 00000000 *UND* 00000000 sum RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 00000007 R_386_32 j 0000000d R_386_32 i 00000013 R_386_PC32 sum 首先，我们注意到符号表里面的sum被标记为UND（undefined），也就是在m.o中没有定义，所以将来要通过 ld（Linux下的链接器）的符号解析功能到别的模块中去查找是否存在函数sum的定义。另外，在重定位表中有三条记录，指出了在重定位过程中代码段中三处需要修改的位置，分别位于7、d和13。下面以一种更加直观的方式来看一下这三个位置： $ objdump -dx m.o Disassembly of section .text: 00000000 : 0: 55 push
