IT评测·应用市场-qidao123.com技术社区

标题: 2-2-18-7 QNX 体系架构-动态链接 [打印本页]

---

作者: 徐锦洪    时间: 2024-12-1 19:16
标题: 2-2-18-7 QNX 体系架构-动态链接
阅读媒介

本文以QNX体系官方的文档英文原版资料为参考，翻译和逐句校对后，对QNX操纵体系的相干概念举行了深度整理，旨在帮助想要相识QNX的读者及开发者可以快速阅读，而不必查看艰涩难明的英文原文，这些文章将会作为一个或多个系列举行发布，从遵从原文的翻译，到针对某些重要概念的穿插引入，以及再到各个重要专题的梳理，大致分为这三个条理部分，分差别的文章举行发布，依据这样的原则举行组织，读者可以更好的查找和理解。

---

1. 动态链接

在一个典型的体系中，将运行许多步调。每个步调都依赖于许多函数，其中一些是“标准的”C库函数，比如printf()， malloc()， write()等。
假如每个步调都使用标准C库，则通常每个步调都会在其内部拥有该C库的唯一副本。不幸的是，这将会导致资源的浪费。由于C库是通用的，因此让每个步调引用该库的公共实例比让每个步调包含该库的副本更有意义。这种方法有几个优点，其中最重要的是节流了总的所需的体系内存。
在我们进一步讨论之前，我们应该先看看以下一些术语：

• Linker
  

链接器，是一种工具，比如 ld，通常在编译步调后立即运行，以便组合对象文件【object files】和归档文件【archive files】，重新定位它们的数据，并解析符号引用【symbol reference】。

• Runtime linker
  

运行时链接器，是一种在运行步调时查找并加载共享对象的工具。运行时链接器，也被称为动态链接器【dynamic linker】，但我们会使用运行时链接器【runtime linker】，而不是【dynamic linker】，从而制止与（非运行时）链接器所做的动态链接【dynamic linking】的概念相混淆。
运行时链接器的名称是ldd（同时ldd也是列举步调所需共享对象的 utility【实用工具】 的名称）。在ELF文件的.interp部分中，对于32位目标体系，它被称为/usr/lib/ldqx.so，对于64位目标体系，它被称为/usr/lib/ldqnx-64.so。您必要在OS映像中包含相应的版本；有关详细信息，请参阅Utilities Reference中的 mkifs 条目。

• Statically linked
  

静态链接，表示步调和它所链接的特定的库，在链接时由链接器举行组合。
这意味着步调和特定库之间的绑定是固定的，并且在链接时就知道了（也就是在步调运行之前就知道了）。这也意味着我们不能改变这种绑定关系，除非我们用新版本的库重新链接步调。
假如您不确定库的正确版本是否在运行时可用，大概您正在测试库的新版本，而您还不想将其作为共享方式举行安装，则可以思量静态链接该步调。
静态链接的步调是根据对象（库）的存档【archive】举行链接的，这些对象（库）的扩展名通常为.a。这种对象集合的一个例子是标准C库，libc.a。

• Dynamically linked
  

动态链接，表示步调和它所引用的特定库，在链接时不会被链接器组合起来。
相反，链接器将信息放入可执行文件中，告诉加载器，代码位于哪个共享对象模块中，以及应该使用哪个运行时链接器来查找和绑定引用。这意味着步调和共享对象之间的绑定是在运行时完成的（在步调启动之前，找到并绑定适当的共享对象）。
这种类型的步调被称为部分绑定可执行步调【partially bound executable】，因为它不是完全解析的：链接器在链接时，并没有使步调中的全部引用符号与库中的特定代码相干联。相反，链接器只是说：“这个步调在一个特定的共享对象中调用一些函数，所以我将记载下这些函数在哪个共享对象中，然后继承。” 实际上，这将绑定操纵耽误到运行时举行。
动态链接的步调，是针对具有.so扩展名的共享对象举行链接的。这种对象的一个例子是标准C库的共享对象版本，libc.so。
您可以使用编译器驱动步调 qcc 的命令行选项来告诉工具链，您是静态链接还是动态链接。然后该命令行选项就决定了所使用的扩展名（是.a还是.so）。

• Augmenting code at runtime【在运行时扩充代码】
  

进一步来说，步调在运行之前可能并不知道必要调用哪些函数。虽然这初看有点奇怪（毕竟，一个步调怎么可能不知道它要调用什么函数呢?），但它确实是一个非常强盛的特性。这是为什么。
比如我们来看一个“通用”磁盘驱动步调。启动，探测硬件，并检测到硬盘。然后，驱动步调动态加载 io-blk 代码来处置惩罚磁盘块，因为它找到了一个面向块【block-oriented】的装备。如今驱动步调开始以块级别访问磁盘，它发现磁盘上存在两个分区：一个DOS分区和一个Power-Safe分区。我们没有强制磁盘驱动步调，必须包含全部它可能遇到的，全部分区类型的文件体系驱动步调，而是尽量保持简单：它（磁盘驱动步调）没有任何的文件体系驱动步调！在运行时，磁盘驱动步调检测到两个分区，然后知道应该加载 fs-dos.so 和 fs-qnx6.so 文件体系代码，来处置惩罚这些分区。
通过推迟决定调用哪些函数，我们增强了磁盘驱动步调的机动性（同时也减小了它的大小）。
1.1. 怎样使用共享对象

为了理解步调怎样使用共享对象，让我们起首看看可执行文件的格式，然后检查步调启动时发生的步调。
ELF format
QNX Neutrino RTOS 使用 ELF（Executable and Linking Format）二进制格式。ELF不但简化了创建共享库的使命，而且还增强了运行时模块的动态加载。
在下图中，我们展示了ELF文件的两个视图：链接视图和执行视图。链接视图在链接步调或链接库时使用，它处置惩罚对象文件中的节【sections】。节【sections】包含大量的对象文件信息：数据【data】、指令【instructions】、重定位信息【relocation information】、符号【symbols】、调试信息【debugging information】等。在步调运行时使用执行视图，执行视图则处置惩罚段【segments】。
在链接时，通过将具有相似属性的节【sections】归并为段【segments】来构建步调或库。通常，全部可执行数据节【executable data sections】和只读数据节【read-only data sections】，归并为单个文本段【text segment】，而 data 及 “BSS” 则归并为 data 段【data segment】。这些段称为加载段【load segments】，因为它们必要在进程创建时加载到内存中。其他部分，如符号信息【symbol information】和调试节【debugging sections】被归并到其他非加载段中。

      

       对象文件格式：链接视图和执行视图       ELF without COFF
大多数 ELF加载器 的实现，都派生自 COFF（Common Object File Format，通用对象文件格式）加载器；它们在加载时使用 ELF对象 的链接视图。这是低效的，因为步调加载器必须使用节加载可执行文件。一个典型的步调可能包含大量的节，每个节都必须位于步调中并分别加载到内存中。
然而，QNX Neutrino 完全不依赖于加载节【sections】的 COFF 技能。在开发我们的 ELF 实现时，我们直接根据 ELF 规范工作，并将效率放在了首位。该ELF加载器使用了步调的“执行视图”。通过这样做，加载步调的使命大大简化：它所要做的就是将步调或库的加载段【load segments】（通常是两个）复制到内存中。因此，进程创建和库的加载操纵要比之前快得多。
1.2. 典型进程的内存布局

下图显示了一个典型进程的内存布局。进程加载段（对应于图中的 text段 和data段），在进程的基地址举行加载。主栈【main stack】位于正下方并向下扩展。任何被创建的其他线程都有它们本身的栈【stack】，位于主栈【main stack】的下方。每个栈【stack】由一个保护页【guard page】举行分隔，以检测栈溢出。堆【heap】位于进程加载段【load segments】上方并向上增长。（load segments，代表的是图中的data segment 和 text segment。）

      

       在x86体系上的进程内存布局       在进程地址空间的中间，为共享对象保留了一个很大的地区。共享库位于地址空间的顶部并向下增长。
创建新进程时，进程管理器起首将可执行文件中的两个段映射到内存中。然后对步调的ELF头举行解码。假如步调头表明可执行文件链接到了共享库，则进程管理器将从步调头中提取动态解释器【dynamic interpreter】的名称。动态解释器指向包含了运行时链接器【runtime linker】代码的共享库【shared library】。进程管理器将在内存中加载此共享库【shared library】，然后将控制权传递给此共享库中的运行时链接器代码。
1.3. 运行时链接器

当启动指向共享对象的步调时，或步调哀求动态加载共享对象时，将调用运行时链接器【runtime linker】。此链接器包含在C运行时库中。
运行时链接器【runtime linker】在加载共享库（.so文件）时，执行如下几个使命：
假如哀求的共享库尚未加载到内存中，则运行时链接器将会加载它：
假如共享库名称是完全限定的【fully qualified】（即以斜杠开头，雷同于“绝对路径”），则直接从指定位置加载它。假如在那里找不到，则不再执行进一步的搜刮。
假如它不是一个完全限定的路径名，链接器将按照如下方式搜刮它：
假如可执行文件的动态节【dynamic section】包含 DT_RPATH 标志，则搜刮 DT_RPATH 指定的路径。
假如没有找到共享库，运行时链接器将在 LD_LIBRARY_PATH 指定的目录中搜刮它。
假如仍然没有找到共享库，那么链接器将搜刮由 LD_LIBRARY_PATH 环境变量 指定的默认库搜刮路径(即 CS_LIBPATH 设置字符串)。假如没有指定，则默认库路径设置为映像文件体系的路径。
一旦找到哀求的共享库，就将其加载到内存中。对于 ELF 共享库，运行时链接器只必要使用两次 mmap() 调用，来将两个加载段映射到内存中，是一个非常高效的操纵。
然后将共享库添加到进程已加载的全部库的内部列表中。运行时链接器【runtime linker】负责维护这个列表。
然后运行时链接器【runtime linker】对共享对象的动态节【dynamic section】举行解码。
此动态节【dynamic section】向链接器提供有关此库所链接的其他库的信息。它还提供了有关必要应用的重定位信息和必要解析的外部符号的信息。运行时链接器，将会起首加载任何其他的所需共享库（这些共享库本身可能也会引用再其他的共享库）。然后，它将处置惩罚每个库的重定位。其中一些重定位是库的当地重定位，而另一些重定位则必要运行时链接器解析全局符号。在后一种情况下，链接器将在库列表中搜刮该符号。在ELF文件中，使用哈希表举行符号查找，因此哈希表查找非常快。在库中搜刮符号的顺序非常重要，我们将在后面的 “Symbol name resolution” 章节中看到这一点。
一旦应用了全部重定位，就会调用在共享库的 init section 中注册的全部初始化函数。在某些 c++ 实现中，也用于调用全局构造函数。
1.4. 在运行时加载共享库

进程可以通过使用 dlopen() 调用，在运行时加载共享库，该调用会指示运行时链接器【runtime linker】加载此库。一旦加载了此库，步调就可以通过使用 dlsym() 调用来确定其地址，从而调用该库中的任何函数。

步调还可以通过使用 dladdr() 调用来确定与给定地址相干联的符号。最后，当进程不再必要共享库时，它可以调用 dlclose() 从内存中卸载库。
1.5. 符号名称解析

当运行时链接器加载共享库时，必须解析该库中的符号。符号解析的顺序和范围很重要。假如一个共享库调用的函数恰好在步调加载的几个库中以相同的名称存在，那么在这些库中搜刮该符号的顺序是至关重要的。这就是为什么OS会定义多个可以在加载库时所使用的选项。
全部具有全局作用域的对象（可执行文件【executables】和库【bibraries】）都存储在一个内部列表（全局列表）中。默认情况下，任何全局作用域对象都会使其全部符号对加载的任何共享库可用。全局列表最初包含了在步调启动时所加载的可执行文件和全部库。
默认情况下，当使用 dlopen() 调用加载新的共享库时，该库中的符号将通过按以下顺序搜刮来举行解析：
由LD_PRELOAD环境变量 指定的库列表。您可以在运行步调时，使用此环境变量来添加或更改功能。
共享库
全局列表
共享库所引用的任何依赖对象（即，共享库链接到的任何其他库）
当使用dlopen()打开共享库时，运行时链接器【runtime linker】的作用域范围，可以通过两种方式改变：
当步调加载一个新库时，它可以通过将RTLD_GLOBAL标志传递给dlopen()调用的方式，来指示运行时链接器将库的符号放在全局列表中。这将使得该库的符号对随后加载的任何库都可用。
对共享库中符号举行解析时，会搜刮对象列表，可以使用修改该对象列表的方式。假如将RTLD_GROUP标志传递给dlopen()，那么只有该库直接引用的对象才会在其中举行符号搜刮。假如传递RTLD_WORLD标志，则只搜刮全局列表中的对象。
2. 梳理理解与总结

在一个典型的体系中，将运行许多步调。每个步调都依赖于许多函数，其中一些是“标准的”C库函数，比如printf()， malloc()， write()等。
假如每个步调都使用标准C库，则通常每个步调都会在其内部拥有该C库的唯一副本。不幸的是，这将会导致资源的浪费。由于C库是通用的，因此让每个步调引用该库的公共实例比让每个步调包含该库的副本更有意义。这种方法有几个优点，其中最重要的是节流了总的所需的体系内存。
Linker
链接器，是一种工具，比如 ld，通常在编译步调后立即运行，以便组合对象文件【object files】和归档文件【archive files】，重新定位它们的数据，并解析符号引用【symbol reference】。
Runtime linker
运行时链接器，是一种在运行步调时查找并加载共享对象的工具。运行时链接器，也被称为动态链接器【dynamic linker】，但我们会使用运行时链接器【runtime linker】，而不是【dynamic linker】，从而制止与（非运行时）链接器所做的动态链接【dynamic linking】的概念相混淆。
运行时链接器的名称是ldd（同时ldd也是列举步调所需共享对象的 utility【实用工具】 的名称）。
Statically linked
静态链接，表示步调和它所链接的特定的库，在链接时由链接器举行组合。
这意味着步调和特定库之间的绑定是固定的，并且在链接时就知道了（也就是在步调运行之前就知道了）。这也意味着我们不能改变这种绑定关系，除非我们用新版本的库重新链接步调。
假如您不确定库的正确版本是否在运行时可用，大概您正在测试库的新版本，而您还不想将其作为共享方式举行安装，则可以思量静态链接该步调。
静态链接的步调是根据对象（库）的存档【archive】举行链接的，这些对象（库）的扩展名通常为.a。这种对象集合的一个例子是标准C库，libc.a。
Dynamically linked
动态链接，表示步调和它所引用的特定库，在链接时不会被链接器组合起来。
相反，链接器将信息放入可执行文件中，告诉加载器，代码位于哪个共享对象模块中，以及应该使用哪个运行时链接器来查找和绑定引用。这意味着步调和共享对象之间的绑定是在运行时完成的（在步调启动之前，找到并绑定适当的共享对象）。
这种类型的步调被称为部分绑定可执行步调【partially bound executable】，因为它不是完全解析的：链接器在链接时，并没有使步调中的全部引用符号与库中的特定代码相干联。相反，链接器只是说：“这个步调在一个特定的共享对象中调用一些函数，所以我将记载下这些函数在哪个共享对象中，然后继承。” 实际上，这将绑定操纵耽误到运行时举行。
动态链接的步调，是针对具有.so扩展名的共享对象举行链接的。这种对象的一个例子是标准C库的共享对象版本，libc.so。
您可以使用编译器驱动步调 qcc 的命令行选项来告诉工具链，您是静态链接还是动态链接。然后该命令行选项就决定了所使用的扩展名（是.a还是.so）。
2.1. 怎样使用共享对象

ELF format
QNX Neutrino RTOS 使用 ELF（Executable and Linking Format）二进制格式。ELF不但简化了创建共享库的使命，而且还增强了运行时模块的动态加载。
在下图中，我们展示了ELF文件的两个视图：链接视图和执行视图。链接视图在链接步调或链接库时使用，它处置惩罚对象文件中的节【sections】。节【sections】包含大量的对象文件信息：数据【data】、指令【instructions】、重定位信息【relocation information】、符号【symbols】、调试信息【debugging information】等。在步调运行时使用执行视图，执行视图则处置惩罚段【segments】。
在链接时，通过将具有相似属性的节【sections】归并为段【segments】来构建步调或库。通常，全部可执行数据节【executable data sections】和只读数据节【read-only data sections】，归并为单个文本段【text segment】，而 data 及 “BSS” 则归并为 data 段【data segment】。这些段称为加载段【load segments】，因为它们必要在进程创建时加载到内存中。其他部分，如符号信息【symbol information】和调试节【debugging sections】被归并到其他非加载段中。

      

       对象文件格式：链接视图和执行视图       2.2. 典型进程的内存布局

下图显示了一个典型进程的内存布局。进程加载段（对应于图中的 text段 和data段），在进程的基地址举行加载。主栈【main stack】位于正下方并向下扩展。任何被创建的其他线程都有它们本身的栈【stack】，位于主栈【main stack】的下方。每个栈【stack】由一个保护页【guard page】举行分隔，以检测栈溢出。堆【heap】位于进程加载段【load segments】上方并向上增长。

在x86体系上的进程内存布局
在进程地址空间的中间，为共享对象保留了一个很大的地区。共享库位于地址空间的顶部并向下增长。
创建新进程时，进程管理器起首将可执行文件中的两个段映射到内存中。然后对步调的ELF头举行解码。假如步调头表明可执行文件链接到共享库，进程管理器将从步调头中提取动态解释器的名称。动态解释器指向包含运行时链接器代码的共享库。进程管理器将在内存中加载此共享库，然后将控制权传递给此库中的运行时链接器代码。
2.3. 运行时链接器

当启动指向共享对象的步调时，或步调哀求动态加载共享对象时，将调用运行时链接器【runtime linker】。此链接器包含在C运行时库中。
运行时链接器【runtime linker】在加载共享库（.so文件）过程请参考：- Runtime linker
2.4. 在运行时加载共享库

进程可以通过使用 dlopen() 调用，在运行时加载共享库，该调用会指示运行时链接器【runtime linker】加载此库。一旦加载了此库，步调就可以通过使用 dlsym() 调用来确定其地址，从而调用该库中的任何函数。
步调还可以通过使用 dladdr() 调用来确定与给定地址相干联的符号。最后，当进程不再必要共享库时，它可以调用 dlclose() 从内存中卸载库。
2.5. 动态链接库使用总结

两种动态链接库的使用方式：
2.5.1. 用步调编译时，通过编译工具链gcc指定和使用动态链接库

创建动态链接库
假设你有一个名为 libmylib.so 的动态链接库，它包含了一个函数 int add(int a, int b);。你必要编写这个库的源代码，比方 mylib.c：
然后，你可以使用 gcc 来编译和创建 .so 文件：
编写使用动态链接库的应用步调
如今，你有一个使用 libmylib.so 库的应用步调。你必要包含相应的头文件（假如有的话），并在编译时指定链接到该库。假设你没有为 add 函数创建头文件，但通常你会这样做。
app.c（使用动态链接库的应用步调）：
留意：在实际开发中，你应该在头文件中声明函数 add，并在 app.c 中包含这个头文件。
编译应用步调并链接到动态链接库
编译应用步调时，你必要使用 -L 选项来指定库文件的搜刮路径，并使用 -l 选项来指定库名（不包括前导的 lib 和后缀的 .so）。
这里 -L. 指定了当前目录为库文件的搜刮路径（假设 libmylib.so 在当前目录下），而 -lmylib 指定了要链接的库名为 mylib。
运行应用步调
在运行应用步调之前，确保动态链接库 libmylib.so 在体系的库路径中，大概在运行应用步调时指定其位置。假如库在当前目录下，你可能必要设置 LD_LIBRARY_PATH 环境变量来包含当前目录：
2.5.2. 直接在应用步调代码中运行时动态加载共享对象（即.so文件）

假设你有一个共享对象文件 libmylib.so，它包含了一个函数 int add(int a, int b);。该函数的实现和创建 .so 文件的过程与前面的示例相同。
编写一个 C 应用步调，该步调在运行时动态加载 libmylib.so 并调用其中的 add 函数。
编译应用步调时，你必要链接 dl 库，因为 dlopen、dlsym 等函数都定义在这个库中。
执行./myapp运行你的应用步调。




免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 IT评测·应用市场-qidao123.com技术社区 (https://dis.qidao123.com/)

Powered by Discuz! X3.4