大体原理基本就这样，但具体实现时，对函数的处理和全局变量有所不同。由于大型程序函数成千上万，而程序很可能只会用到其中的一小部分，因此没必要加载的时候把所有的函数都做重定位，只有在用到的时候才对地址做修订，为此编译器引入了过程链接表PLT（Procedure Linkage Table）来实现延时绑定。PLT在代码段中，它指向了GOT中函数对应的地址，第一次调用时候，GOT存放的不是函数的实际地址，而是PLT跳转到GOT代码的后一条指令地址，这样第一次通过PLT跳转到GOT，然后通过GOT又调回到PLT的下一条指令，相当于什么也没做，紧接着PLT后面的代码会将动态链接需要的参数入栈，然后调用动态链接器修正GOT中的地址，从这以后，PLT中代码跳转到GOT的地址就是函数真正的地址，从而实现了所谓的延时绑定。
对共享目标文件而言，有几个需要关注的section：
有了以上基础后，我们看一下动态链接的过程：
1. 装载过程中程序执行会跳转到动态链接器
2. 动态链接器自举通过GOT、.dynamic信息完成自身的重定位工作
3. 装载共享目标文件：将可执行文件和链接器本身符号合并入全局符号表，依次广度优先遍历共享目标文件，它们的符号表会不断合并到全局符号表中，如果多个共享对象有相同的符号，则优先载入的共享目标文件会屏蔽掉后面的符号
4. 重定位和初始化
问题三：全局符号介入动态链接过程中最关键的第3步可以看到，当多个共享目标文件中包含一个相同的符号，那么会导致先被加载的符号占住全局符号表，后续共享目标文件中相同符号被忽略。当我们代码中没有很好的处理命名的话，会导致非常奇怪的错误，幸运的话立刻core dump，不幸的话直到程序运行很久以后才莫名其妙的core dump，甚至永远不会core dump但是结果不正确。
如下图所示，main.cpp中会用到两个动态库libadd.so，libadd1.so的符号，我们把重点
放在Add函数的处理上，当我们以g++ main.cpp libadd.so libadd1.so编译时，程序输出“Add in add lib”说明Add是用的libadd.so中的符号（add.cpp），当我们以g++ main.cpp libadd1.so libadd.so编译时，程序输出“Add in add1 lib”说明Add是用的libadd1.so中的符号，这时候问题就大了，调用方main.cpp中认为Add只有两个参数，而add1.cpp中认为Add有三个参数，程序中如果有这样的代码，可以预见很可能造成巨大的混乱。具体符号解析我们可以通过LD_DEBUG=all ./a.out来观察Add的解析过程，如下图所示：左边是对应libadd.so在编译时放在前面的情况，Add绑定在libadd.so中，右边对应libadd1.so放前面的情况，Add绑定在libadd1.so中。
有了动态链接和共享目标文件的加持，Linux提供了一种更加灵活的模块加载方式：通过提供dlopen，dlsym，dlclose，dlerror几个API，可以实现在运行的时候动态加载模块，从而实现插件的功能。
如下代码演示了动态加载Add函数的过程，add.cpp按照正常编译“g++ -fPIC –shared –o libadd.so add.cpp”成libadd.so，main.cpp通过“g++ main.cpp -ldl”编译为a.out。main.cpp中首先通过dlopen接口取得一个句柄void *handle，然后通过dlsym从句柄中查找符号Add，找到后将其转化为Add函数，然后就可以按照正常的函数使用，最后dlclose关闭句柄，期间有任何错误可以通过dlerror来获取。
