上文 静态链接过程分析 讲解了静态链接的过程，尤其强调了重定位的过程。本文将继续介绍动态链接的过程。
静态链接得到的可执行程序，被操作系统加载之后就可以直接执行。
因为在链接的时候，链接器已经把所有目标文件中的代码、数据等 Section，都组装到可执行文件中了。并且把代码中所有使用的外部符号（变量、函数），都进行了重定位（即：把变量、函数的地址，都填写到代码段中需要重定位的地方），因此可执行程序在执行的时候，不依赖于其它的外部模块即可运行。
这里的前提是可执行文件是可写的。
而对于动态链接来说，在编译阶段，仅仅是在可执行文件或者动态库中记录了一些必要的信息。
真正的重定位过程，是在这个时间点来完成的：可执行程序、动态库被加载之后，调用可执行程序的入口函数之前。
只有当所有需要被重定位的符号被解决了之后，才能开始执行程序。既然也是重定位，与静态链接过程一样：也需要把符号的目标地址填写到代码段中需要重定位的地方。
但是对于动态链接，这里有个问题：对于内存的访问是有权限控制的，一般来说：
- 代码段：可读、可执行
- 数据段：可读、可写
如果进行符号重定位，就需要对代码进行修改（填写符号的地址），但是代码段又没有可写的权限，那该怎么办呢？
要解决这个问题，那就涉及到了 Linux 中的动态链接器的核心工作。
既然代码段在被加载到内存中之后不可写，但是数据段是可写的。在代码段中引用的外部符号，可以在数据段中增加一个跳板：让代码段先引用数据段中的内容，然后在重定位时，把外部符号的地址填写到数据段中对应的位置，如下图所示：
下面还是来结合简单的示例来分析：
我们需要 3 个源文件来讨论动态链接中重定位的过程：、、，其中的 和 被编译成动态库，然后 与这两个动态库一起动态链接成可执行程序。它们之间的依赖关系是：
代码如下：
定义一个全局变量和一个全局函数，被 调用。
- 定义了 2 个全局变量：一个静态，一个非静态；
- 定义了 3 个函数： 是静态函数，只能在本文件中调用； 和 是全局函数，可以被外部调用
- 在 中会调用 。
- 利用 函数（第一个参数传入 NULL），来打印此进程中的一些符号信息（变量和函数）
- 赋值给 中的变量 a2，然后调用 中的 函数
然后将这三个源文件编译成动态库和可执行文件：
- 参数意思是：生成位置无关代码（Position Independent Code），这也是动态链接中的关键
- 既然动态库是在运行时加载，那为什么在编译的时候还需要指明?因为在编译的时候，需要知道每一个动态库中提供了哪些符号。Windows 中的动态库的显性的导出和导入标识，更能体现这个概念()。
然后我们可以用 工具来查看一个可执行文件或动态库依赖于哪个模块：
当执行 main 程序的时候，操作系统首先把 main 加载到内存，然后通过 段信息来查看该文件依赖哪些动态库：
上图中的字符串 ，就表示 main 依赖动态链接库。
也是一个动态链接库，在大部分情况下动态链接库已经被加载到内存中了（动态链接库就是为了共享），操作系统此时只需要把动态链接库所在的物理内存，映射到 main 进程的虚拟地址空间中就可以了，然后再把控制权交给动态链接器。
然后，动态链接器发现：main 依赖 ，于是它就在虚拟地址空间中找一块能放得下 的空闲空间，然后把 中需要加载到内存中的代码段、数据段都加载进来。当然，在加载 时，又会发现它依赖 ，于是又把在虚拟地址空间中找一块能放得下 的空闲空间，把 中的代码段、数据段等加载到内存中，示意图如下所示：
动态链接器自身也是一个动态库，而且是一个特殊的动态库：它不依赖于其他的任何动态库，因为当它被加载的时候，没有人帮它去加载依赖的动态库，否则就变成死循环了。
一个进程在运行时的实际加载地址(或者说虚拟内存区域)，可以通过指令读取出来：
这里插个问题，当我运行 main 的时候，报了如下的错误：
然后，我用 命令检查了一下 main 的动态库依赖关系：
至于找不到的情况分为两种:
- 系统里根本不存在 库；
- 库在系统中存在，但是动态链接器找不到，即 库的位置没有告知动态链接器。
系统里当然找不到 ，因为这是我们自己写的。所以问题出现的原因是第二条。
当然还要包含
所以，只要把动态库 的绝对路径添加到动态链接器的搜索路径中，那么动态链接器就可以获取到动态库 的绝对路径，接着就可以找到动态库文件 ，将动态库文件载入内存，然后就可以使用动态库里面的代码，最终可执行程序 main 就可以成功运行，不会报错。
动态链接器搜索动态库绝对路径的搜索顺序为： 段→环境变量 → 文件列表→ 或 目录。
因此，添加动态库绝对路径的方法也有很多种
接下来，我们就按照上述分析进行操作。
这里有两个方法，一个是临时的，一个是永久性的。
- 临时环境变量
输入命令（注意路径改成自己的动态库所在的路径）：
然后可以 echo 这个变量检查一下：
现在 main 的链接正常了：
- 环境变量
在 里输入：
然后退出，在使能刷新一下：
一样可以，这里就不演示了。
再打开一个终端，找到 main 的进程号：
输入命令 可以看到当我的虚拟机中执行 main 程序时，看到的地址信息是：
另外，还可以看到 C 库（）、动态链接器（）以及动态加载库 的虚拟地址区域，布局如下：
代码段 rx，数据段 rw
可以看出 main 可执行程序是位于低地址，所有的动态库都位于 4G 内存空间的最后 1G 空间中。
还有另外一个指令也很好用 ，也可以打印出每个模块的内存地址：
在上一篇文章的静态链接中学习过，链接器在扫描每一个目标文件( 文件)的时候，会把每个目标文件中的符号提取出来，构成一个全局符号表。
然后在第二遍扫描的时候，查看每个目标文件中需要重定位的符号，然后在全局符号表中查找该符号被安排在什么地址，然后把这个地址填写到引用的地方，这就是静态链接时的重定位。
但是动态链接过程中的重定位，与静态链接的处理方式差别就大很多了，因为每个符号的地址只有在运行的时候才能知道它们的地址。例如： 引用了 中的变量和函数，而 中的这两个符号被加载到什么位置，直到 main 程序准备执行的时候，才能被链接器加载到内存中的某个随机的位置。
也就是说：动态链接器知道每个动态库中的代码段、数据段被加载的内存地址，因此动态链接器也会维护一个全局符号表，其中存放着每一个动态库中导出的符号以及它们的内存地址信息。
在示例代码 函数中，我们通过 返回的句柄来打印进程中的一些全局符号的地址信息，输出内容如下：
可以看到：在全局符号表中，没有找到 中的变量 a1 和函数 这两个符号，因为它俩都是 static 类型的，在编译成动态库的时候，没有导出到符号表中。
动态链接库中保护两个符号表：
- ：动态符号表: 表示模块中符号的导出、导入关系)
- ：符号表: 表示模块中的所有符号
在示例代码中， 是比较特殊的，它既被 main 可执行程序所依赖，又依赖于 。而且，在 中，定义了静态、动态的全局变量和函数，可以很好的概况很多种情况，因此这部分内容就主要来分析 这个动态库。
前文说过：代码重定位需要修改代码段中的符号引用，而代码段被加载到内存中又没有可写的权限，动态链接解决这个矛盾的方案是：增加一层间接性。
例如： 的代码中引用了 中的变量 b，在 的代码段，并不是在引用的地方直接指向 数据段中变量 b 的地址，而是指向了 自己的数据段中的某个位置，在重定位阶段，链接器再把 中变量 b 的地址填写到这个位置。
因为 自己的代码段和数据段位置是相对固定的，这样的话， 的代码段被加载到内存之后，就再也不用修改了。而数据段中这个间接跳转的位置，就称作：全局偏移表(，Global Offset Table)。
的代码段中引用了 中的符号 b，既然 b 的地址需要在重定位时才能确定，那么就在数据段中开辟一块空间（GOT表)，重定位时把 b 的地址填写到 GOT 表中。
而 的代码段中，把 GOT 表的地址填写到引用 b 的地方，因为 GOT 表在编译阶段是可以确定的，使用的是相对地址。这样，就可以在不修改 代码段的前提下，动态地对符号 b 进行了重定位！
其实，在一个动态库中存在 2 个 GOT 表，分别用于重定位变量符号（section 名称：）和函数符号（section 名称：）。也就是说：
- 所有变量类型的符号重定位信息都位于 中
- 所有函数类型的符号重定位信息都位于 中
并且，在一个动态库文件中，有两个特殊的段（ 和 ）来告诉链接器： 和 这两个表中，有哪些符号需要进行重定位。
为了更深刻的理解 和 这两个表，有必要来拆解一下 动态库文件的内部结构。
通过 指令来看一下这个 ELF 文件中都有哪些 section：
段
在静态链接，elf文件有一个文件头，里面记录了一些静态链接所需要的信息，比如比如需要的符号表，重定位表等。
而在共享对象中，需要动态链接的变量和函数也需要相应的信息，为了方便动态链接器的执行，在共享对象中，有一个专门的 段，汇总了和动态链接有关的段的信息，方便动态链接器使用。
可以看到：一共有 29 个 section，其中的 22、23 就是两个 GOT 表。
另外，从装载的角度来看，装载器并不是把这些 sections 分开来处理，而是根据不同的读写属性，把多个 section 看做一个segment（ELF 的运行视图）。再次通过指令 ，来查看一下 segment 信息：
注意看上面两张图红圈部分的地址信息
由上面两张图可以看出：
- section 0~18 都是可读、可执行权限，被当做一个 segment
- section 19 ~ 25 都是可读、可写的权限，被当作另一个 segment
再来重点看一下 和 这两个 section，可见：
- 和 与数据段一样，都是可读、可写的，所以被当做同一个 segment 被加载到内存中。
通过以上这 2 张图(红色矩形框)，可以得到 动态库文件的内部结构如下：
来继续观察 文件 segment 信息中的 列，它表示的是被加载到虚拟内存中的地址：
因为编译动态库时，使用了代码位置无关参数（)，这里的虚拟地址从 开始。
当 的代码段、数据段被加载到内存中时，动态链接器找到一块空闲空间，这个空间的开始地址，就相当于一个基地址。
中的代码段和数据段中所有的虚拟地址信息，只要加上这个基地址，就得到了实际虚拟地址。所以结合前面的信息可得：
现在，我们已经知道了 库的文件布局，也知道了它的虚拟地址，此时就可以来进一步的看一下 和 这两个表的内部结构了。从刚才的图片中看出：
- 表的长度是 0x18，说明有 6 个表项(每个表项占 4 个字节)
- 表的长度是 0x18，说明有 6 个表项
上文已经说过，这两个表是用来重定位所有的变量和函数等符号的。那么： 通过什么方式来告诉动态链接器需要对 和 这两个表中的表项进行地址重定位呢？
- 在静态链接的时候，目标文件是通过两个重定位表 和 这两个段信息来告诉链接器的。
- 对于动态链接来说，也是通过两个重定位表来传递需要重定位的符号信息的，只不过名字有些不同： 和 。
通过指令 来查看重定位信息：
由上图可以看出：
- 引用了外部符号 b，类型是 ，这个符号的重定位描述信息在 段中
- 引用了外部符号 func_b, 类型是 ，这个符号的重定位描述信息在 段中
由上图可以看出：
- 的代码中在操作变量 b 的时候，就到 表中的 这个地址处来获取变量 b 的真正地址
- 的代码中在调用 func_b 函数的时候，就到 表中的 这个地址处来获取函数的真正地址
下面就来反汇编一下 ，看一下指令码中是如何对这两个表项进行寻址的。
执行反汇编指令：，这里只贴出 func_a1 函数的反汇编代码：
的功能是：把下一条指令()的地址存储到 %ebx 中，也就是：
然后执行: ，让 %ebx 加上 0x2de5，结果就是：。
看下前面的图， 正是 表的开始地址！
紧接着看第二个红框。
- ：先用 %ebx 减去 0x8 的结果，存储到 %eax 中，结果是：，这个地址正是变量 b 在 表中的虚拟地址。
- ：在把 0x1f(十进制就是 31)，存储到 0x3fec 表项中存储的地址所对应的内存单元中（的数据段中的某个位置）。
因此，当链接器进行重定位之后，0x3fec 表项中存储的就是变量 b 的真正地址，而上面这两步操作，就把数值 31 赋值给变量 b 了。
第 3 个红色矩形框，是调用函数 func_b，稍微复杂一些，跳转到符号 的地方，看一下反汇编代码：
指令调用了 （得到 0x400c）处的那个函数指针，从上面的 布局图中可以看出，重定位之后这个表项中存储的正是 func_b 函数的地址（ 中代码段的某个位置），所以就正确的跳转到该函数中了。
实际应用中，共享对象可能会访问大量的外部函数，也就是说，有一个庞大的 表。
当加载该共享对象时，理论上，动态链接器就要将该共享对象涉及到的外部模块全部加载并链接，这可能会耗费大量时间，而且，很多外部函数，也许在整个进程生命周期内，都不会被实际调用一次，加载消耗的时间就浪费了。
为了优化这一点，引入延迟绑定（lazy binding）技术。具体办法是，调用外部函数的指令不直接从 中取函数地址，而是新建一个plt段，从这个里面取函数的地址。
假设，某个共享对象 a 访问共享对象 b 中的 bar 函数，那么，在 和 都有一个 bar 函数的项。
plt 中的 bar 函数的项的内容是：
我们来分析一下这几句话。
我们假设一个场景，即共享对象在实际执行时，第一次实际调用 bar 函数，这个时机正是体现延迟绑定技术的时候。
这句话是说跳转到 中 bar 函数的地址，我们知道，因为采用了延迟绑定， 此时这里的地址并不是 bar 的地址。那是什么地址呢？答案是链接器在初始化时，已经帮我们填好了，就是下一条 push 指令的地址。
于是，跳转到了下一条 push 语句，这个语句的 n 又是什么呢？
答案是，为了实现延迟绑定，还建了一个新的段，。这个段也是一个重定位表，记录了 中的 bar 的位置，告诉链接器，这个 bar 的位置要进行重定位。n 就是 bar 函数在 中的位置。我们可以将其称作 bar 函数的 id。
接下来，，是把 bar 所在的模块的 id 入栈。
回顾上面两个 push，我们看到，入栈了模块的 id，以及要使用该模块的函数 bar 的 id n。
然后调用 ，该函数就帮我们加载并链接要使用的外部模块，并在 中更新 bar 函数的地址。该函数会使用到我们刚刚 push 的两个值，这是它领受的任务。
一旦这个过程完成，再次通过 调用 bar 函数时，就会跳转到真正的 bar 函数了。
总结一下，为了实现延迟绑定，又引入了两个新的段， 和 。
到此这篇动态库（动态库存表的详细制作过程）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/bcyy/58410.html