How To Write Shared Libraries(9)

1.5.2 Symbol Relocations (2)

Note that there is no problem if the scope contains more than one definition of the same symbol. The symbol lookup algorithm simply picks up the first definition it finds. Note that a definition in a DSO being weak has no effects. Weak definitions only play a role in static linking. Having multiple definitions has some perhaps surprising consequences. Assume DSO ‘A’ defines and references an interface and DSO ‘B’ defines the same interface. If now ‘B’ precedes ‘A’ in the scope, the reference in ‘A’ will be satisfied by the definition in ‘B’. It is said that the definition in ‘B’ interposes the definition in ‘A’. This concept is very powerful since it allows more special- ized implementation of an interface to be used without replacing the general code. One example for this mech- anism is the use of the LD PRELOAD functionality of the dynamic linker where additional DSOs which were not present at link-time are introduced at run-time. But inter- position can also lead to severe problems in ill-designed code. More in this in section 1.5.4.
请注意，如果作用域包含同一个符号的多个定义，则没有问题。符号查找算法只是选取它找到的第一个定义。注意，DSO中的定义是弱的，没有任何影响。弱定义只在静态链接中起作用。拥有多个定义可能会产生一些令人惊讶的结果。假设DSO ' A '定义并引用了一个接口，而DSO ' B '定义了同一个接口。如果现在在作用域中' B '位于' A '之前，' B '中的定义将满足' A '中的引用。据说“B”中的定义插入了“A”中的定义。这个概念非常强大，因为它允许在不替换常规代码的情况下使用更特殊的接口实现。这种机制的一个例子是使用动态连接器的LD PRELOAD功能，其中在运行时引入了在链接时不存在的额外DSOs。但是在设计不良的代码中，插入也会导致严重的问题。更多内容见第1.5.4节。(有道翻译)

Looking at the algorithm it can be seen that the perfor- mance of each lookup depends, among other factors, on the length of the hash chains and the number of objects in the lookup scope. These are the two loops described above. The lengths of the hash chains depend on the number of symbols and the choice of the hash table size. Since the hash function used in the initial step of the algo- rithm must never change these are the only two remaining variables. Many linkers do not put special emphasis on selecting an appropriate table size. The GNU linker tries to optimize the hash table size for minimal lengths of the chains if it gets passed the -O option (note: the linker, not the compiler, needs to get this option).
查看算法可以看出，每个查找的性能取决于哈希链的长度和查找范围内对象的数量等因素。这就是上面描述的两个循环。哈希链的长度取决于符号的数量和哈希表大小的选择。由于在算法的初始步骤中使用的哈希函数永远不能改变，这是仅剩下的两个变量。许多链接器没有特别强调选择适当的表大小。如果传递了-O选项(注意:链接器需要获得这个选项，而不是编译器)，GNU链接器会尝试优化哈希表的大小以使链的长度最小。（有道翻译）

A note on the current implementation of the hash table op- timization. The GNU binutils linker has a simple minded heuristic which often favors small table sizes over short chain length. For large projects this might very well in- crease the startup costs. The overall memory consumption will be sometimes significantly reduced which might com- pensate sooner or later but it is still advised to check the effectiveness of the optimization. A new linker implemen- tation is going to be developed and it contains a better algorithm.
关于哈希表优化的当前实现的注释。GNU binutils链接器具有一个简单的启发式，它通常倾向于小表而不是短链长度。对于大型项目来说，这很可能会增加启动成本。总体内存消耗有时会显著减少，这可能迟早会补偿，但仍然建议检查优化的有效性。一个新的链接器实现将被开发，它包含一个更好的算法。（有道翻译）