工具接口标准(TIS)可执行链接格式(ELF)规范-卷III-操作系统特性-程序加载和动态链接（五）

本文是对Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification Version 1.2的翻译
工具接口标准(TIS)可执行链接格式(ELF)规范版本 1.2
翻译以中英对照方式，英语水平有限，如有翻译不当的地方，请谅解。

Hash Table
哈希表
A hash table of Elf32_Word objects supports symbol table access. Labels appear below to help explain the hash table organization, but they are not part of the specification.
一个Elf32_Word对象的哈希表支持符号表访问。下面出现的标签帮助解释了哈希表的组织，但是它们不是标准的一部分。

Figure2-8.  Symbol Hash Table

图2-8.符号哈希表

nbucket

nchain

bucket[0] . . . bucket[nbucket-1]

chain[0] . . . chain[nchain-1]

The bucket array contains nbucket entries, and the chain array contains nchain entries; indexes start at 0. Both bucket and chain hold symbol table indexes. Chain table entries parallel the symbol table. The number of symbol table entries should equal nchain; so symbol table indexes also select chain table entries. A hashing function (shown below) accepts a symbol name and returns a value that may be used to computea bucket index. Consequently, if the hashing function returns the value x for some name, bucket[x%nbucket] gives an index, y, into both the symbol table and the chain table. If the symbol table entry is not the one desired, chain[y] gives the next symbol table entry with the same hash value. One can follow the chain links until either the selected symbol table entry holds the desired name or the chain entry contains the value STN_UNDEF.
bucket数组包含nbucket个条目，chain数组包含nchain个条目；索引从0开始。bucket和chain包含符号表索引。chain表条目并行化符号表。符号表条目的个数应该等于nchain；所以符号表索引也可以选择chain表条目。一个哈希函数（下面描述）接受一个符号名并返回一个用于计算bucket索引的值。因此，假如这个哈希函数对某个名字返回值x，bucket[x%nbucket]给出一个索引y，同时可以用于符号表和chain表。假如符号表条目不是一个需要的符号，chain[y]给出下一个符号表条目。跟随chain链直到选择的符号表包含期望的名字或chain条目包含名字的值为STN_UNDEF。

Figure 2-9. Hashing Function
图2-9.哈希函数
unsigned long elf_hash(const unsigned char *name)
{
unsigned long h = 0, g;
while (*name)
{
h = (h << 4) + *name++;
if (g = h & 0xf0000000)
h ^= g >> 24;
h &= ~g;
}
return h;
}

Initialization and Termination Functions
初始化和结束函数
After the dynamic linker has built the process image and performed the relocations, each shared object gets the opportunity to execute some initialization code. All shared object initializations happen before the executable file gains control.
在动态链接器已经建立进程映像并执行重定位后，每个共享对象获得执行一些初始化代码的机会。所有的共享对象初始化发生在可执行文件获取控制前。

Before the initialization code for any object A is called, the initialization code for any other objects that object A depends on are called. For these purposes, an object A depends on another object B, if B appears in A’s list of needed objects (recorded in the DT_NEEDED entries of the dynamic structure). The order of initialization for circular dependencies is undefined.
在任意对象A的初始化代码调用前，对象A依赖的其他对象的初始化代码会被调用。为了这些目的，一个对象A依赖于另外的对象B，假如B出现在A的需求对象列表（动态结构中记录在DT_NEEDED条目中）。初始化环状依赖的顺序未定义。

The initialization of objects occurs by recursing through the needed entries of each object. The initialization code for an object is invoked after the needed entries for that object have been processed. The order of processing among the entries of a particular list of needed objects is unspecified.
对象初始化发生在递归遍历每个对象的依赖入口时。一个对象的初始化代码在该对象的依赖入口处理之后被调用。详细的依赖对象列表入口的处理顺序未指定。

NOTE. Each processor supplement may optionally further restrict the algorithm used to determine the order of initialization. Any such restriction, however, may not conflict with the rules described by this specification.
注意：每个处理器补充说明可能在将来可选择性的限制用于决定初始化顺序的算法。然而，任何一个这样的限制都不会和本规范中描述的规则冲突。

The following example illustrates two of the possible correct orderings which can be generated for the example NEEDED lists. In this example the a.out is dependent on b, d, and e. b is dependent on d and f, while d is dependent on e and g. From this information, a dependency graph can be drawn. The above algorithm on initialization will then allow the following specified initialization orderings among others.
以下例子阐明了2个可能的生成例子的依赖列表的正确顺序。在此例子中，a.out依赖于b、d和e。b依赖于d和f，同时，d依赖于e和g。从这些信息，一个依赖图能够被画出来。上面的初始化算法允许以下的特定初始化顺序。

Figure 2-10. Initialization Ordering Example


Similarly, shared objects may have termination functions, which are executed with the at exit(BA_OS) mechanism after the base process begins its termination sequence. The order in which the dynamic linker calls termination functions is the exact reverse order of their corresponding initialization functions. If a shared object has a termination function, but no initialization function, the termination function will execute in the order it would have as if the shared object's initialization function was present. The dynamic linker ensures that it will not execute any initialization or termination functions more than once.
相似的，共享对象可能有终止函数，终止函数随着退出机制在基础处理开始它的终止序列后被执行。动态链接器调用终止函数的顺序是相应初始化函数确切的反向顺序。假如一个共享对象有终止函数，如果一个共享对象有终止函数，却没有初始化函数，在假设共享对象初始化函数是出现了的情况下，终止函数仍然会以它应该有的顺序执行。动态链接器确保不会执行任何的初始化或终止函数超过一次。

Shared objects designate their initialization and termination functions through the DT_INIT and DT_FINI entries in the dynamic structure, described in "Dynamic Section'' above. Typically, the code for these functions resides in the .init and .fini sections, mentioned in "Sections" of Chapter 1.
共享对象通过动态结构中的DT_INIT和DT_FINI入口指派它们的初始化或终止函数，在上面的“动态分节”部分由描述。典型的，这些函数的代码位于.init和.fini分节，在章节1的“分节”有提到过。

NOTE. Although the atexit(BA_OS) termination processing normally will be done, it is not guaranteed to have executed upon process death. In particular, the process will not execute the termination processing if it calls _exit[see exit (BA_OS)] or if the process dies because it received a signal that it neither caught nor ignored.
注意：虽然退出时的终止处理一般会被执行。但不保证在进程死亡时被执行。特别的，在通过调用_exit或进程由于接收到一个它不会捕获或忽略的信息而死亡的情况下，进程不会执行终止处理。

The dynamic linker is not responsible for calling the executable file's .init section or registering the executable file's .fini section with atexit(BA_OS). Termination functions specified by users via the atexit(BA_OS) mechanism must be executed before any termination functions of shared objects.
动态链接器不会负责调用可执行文件的.init分节或注册可执行文件的.fini分节。终止函数由用户经由退出机制指定，必须在任意共享对象终止函数前执行。