==================== Dynamic Linking （动态链接） =====================
一个可执行文档可能有一个 PT_INTERP 程式头元素。在 exec(BA_OS) 的
过程中，系统从 PT_INTERP 段中取回一个路径名并由解释器文档的段创建初始的
进程映像。也就是说，系统为解释器“编写”了一个内存映像，而不是使用原始
的可执行文档的段映像。此时该解释器就负责接收系统来的控制并且为应用程式
提供一个环境变量。
解释器使用两种方法中的一种来接收系统来的控制。首先，他会接收一个文档描述符
来读取该可执行文档，定位于开头。他能够使用这个文档描述符来读取 并且（或）
映射该可执行文档的段到内存中。其次，依赖于该可执行文档的格式，系统会载入
这个可执行文档到内存中而不是给该解释器一个文档描述符。伴随着可能的文档描述符
异常的情况，解释器的初始进程声明应匹配该可执行文档应当收到的内容。解释器本身
并无需第二个解释器。一个解释器可能是个共享对象也可能是个可执行文档。
* 一个共享对象（通常的情况）在被载入的时候是位置无关的，各个进程可能不同；
系统在 mmap(KE_OS) 使用的动态段域为他创建段和相关的服务。因而，一个
共享对象的解释器将不会和原始的可执行文档的原始段地址相冲突。
* 一个可执行文档被载入到固定地址；系统使用程式头表中的虚拟地址为其创建段。
因而，一个可执行文档解释器的虚拟地址可能和第一个可执行文档相冲突；这种
冲突由解释器来解决。
Dynamic Linker（动态链接器）
当使用动态链接方式建立一个可执行文档时，链接器把一个 PT_INTERP 类型
的元素加到可执行文档中，告诉系统把动态链接器做为该程式的解释器。
注意：由系统提供的动态链接器是和特定处理器相关的。
Exec(BA_OS) 和动态链接器合作为程式创建进程，必须有如下的动作：
* 将可执行文档的内存段加入进程映像中；
* 将共享对象的内存段加入进程映像中；
* 为可执行文档和他的共享对象进行重定位；
* 假如有一个用于读取可执行文档的文档描述符传递给了动态链接器，那么关闭他。
* 向程式传递控制，就象该程式已直接从 exec(BA_OS) 接收控制相同。
链接器同时也为动态链接器构建各种可执行文档和共享对象文档的相关数据。就象
在上面“程式头”中说的那样，这些数据驻留在可载入段中，使得他们在执行过程
中有效。（再一次的，要记住精确的段内容是处理器相关的。能够参阅相应处理器
的补充说明来获得详尽的信息。）
* 一个具备 SHT_DYNAMIC 类型的 .dynamic section 包含各种数据。驻留在
section 开头的结构包含了其他动态链接信息的地址。
* SHT_HASH 类型的 .hash section 包含了一个 symbol hash table.
* SHT_PROGBITS 类型的 .got 和 .plt section 包含了两个分离的 table:
全局偏移表和过程链接表。 下面的 section 演示了动态链接器使用和改变
这些表来为 object file 创建内存映像。
由于每一个遵循 ABI 的程式从一个共享对象库中输入基本的系统服务，因此动态
链接器分享于每一个遵循 ABI 的程式的执行过程中。
就象在处理器补充说明的“程式载入”所解释的那样，共享对象也许会占用和记录在
文档的程式头表中的地址不同的虚拟内存地址。动态链接器重定位内存映像，在应用程式
获得控制之前更新绝对地址。尽管在库被载入到由程式头表指定的地址的情况下绝对地址
应当是正确的，通常的情况却不是这样。
假如进程环境 [see exec(BA_OS)] 包含了一个非零的 LD_BIND_NOW 变量，
动态链接器将在控制传递到程式之前进行任何的重定位。举例而言，任何下面的
环境入口将指定这种行为。
* LD_BIND_NOW=1
* LD_BIND_NOW=on
* LD_BIND_NOW=off
其他情况下， LD_BIND_NOW 或不在环境中或为空值。动态链接器能够不急于
处理过程链接表入口，因而避免了对没有调用的函数的符号解析和重定位。参阅
"Procedure Linkage Table"获取更多的信息。
Dynamic Section（动态section）
假如一个object文档参和动态的连接，他的程式头表将有一个类型为PT_DYNAMIC
的元素。该“段”包含了.dynamic section。一个_DYNAMIC特别的符号，表明了
该section包含了以下结构的一个数组。
Figure 2-9: Dynamic Structure
typedef struct {
Elf32_Sword d_tag;
union {
Elf32_Sword d_val;
Elf32_Addr d_ptr;
} d_un;
} Elf32_Dyn;
extern Elf32_Dyn _DYNAMIC[];
对每一个有该类型的object，d_tag控制着d_un的解释。
* d_val
那些Elf32_Word object描绘了具备不同解释的整形变量。
* d_ptr
那些Elf32_Word object描绘了程式的虚拟地址。就象以前提到的，在执行时，
文档的虚拟地址可能和内存虚拟地址不匹配。当解释包含在动态结构中的地址
时是基于原始文档的值和内存的基地址。为了一致性，文档不包含在
重定位入口来纠正在动态结构中的地址。
以下的表格总结了对可执行和共享object文档需要的tag。假如tag被标为
mandatory，ABI-conforming文档的动态连接数组必须有一个那样的入口。
同样的，“optional”意味着一个可能出现tag的入口，但是不是必须的。
Figure 2-10: Dynamic Array Tags, d_tag
Name Value d_un Executable Shared Object
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
