How To Write Shared Libraries(20)

2 Optimizations for DSOs(1)

In this section we describe various optimizations based on C or C++ variables or functions. The choice of variable or function, unless explicitly said, is made deliber- ately since many of the implementations apply to the one or the other. But there are some architectures where functions are handled like variables.
本节分析c/c++变量和函数的优化。除非明确说明，都有有意选取的实现内容。但有一些架构中，函数像变量一样处理。
This is mainly the case for embedded RISC architectures like SH-3 and SH-4 which have limitations in the addressing modes they provide which make it impossible to implement the function handling as for other architectures.
这主要适用于像SH-3和SH-4这样的嵌入式RISC体系结构，它们提供的寻址模式有局限性，这使得它们不可能像其他体系结构那样实现函数处理。（有道翻译）
In most cases it is no problem to apply the optimizations for variables and functions at the same time. This is what in fact should be done all the time to achieve best performance across all architectures.一般情况下使用优化处理变量和函数没有问题。这就是所有需要完成的提高性能的地方。

The most important recommendation is to always use -fpic or -fPIC when generating code which ends up in DSOs. This applies to data as well as code. Code which is not compiled this way almost certainly will contain text relocations. For these there is no excuse. Text relocations requires extra work to apply in the dynamic linker. And argumentation saying that the code is not shared because no other process uses the DSO is invalid. In this case it is not useful to use a DSO in the first place; the code should just be added to the application code.
最主要的推荐是生成DSO的文件添加编译参数-fpic或者-fPIC。数据和代码都使用。没有使用该参数的代码总是饱含重定位代码。这是必须的内容。代码重定位需要链接器额外的工作。这样代码是不共享的，因为没有其他过程使用。这种情境下在DSO中重定位没用。代码只要加载到应用代码中就OK了。

Some people try to argue that the use of -fpic/-fPIC on some architectures has too many disadvantages. This is mainly brought forward in argumentations about IA- 32.
一些人会认为使用-fpic/-fPIC在一些架构上有许多缺点。这主要是IA-32.
Here the use of %ebx as the PIC register deprives the compiler of one of the precious registers it could use for optimization. But this is really not that much of a problem. First, not having %ebx available was never a big penalty. Second, in modern compilers (e.g., gcc after release 3.1) the handling of the PIC register is much more flexible.
这里使用%ebx作为PIC寄存器剥夺了编译器可以用于优化的一个宝贵寄存器。但这并不是什么大问题。首先，没有%ebx从来都不是什么大问题。其次，在现代编译器中(例如3.1版之后的gcc)， PIC寄存器的处理要灵活得多。（有道翻译）
It is not always necessary to use %ebx which can help eliminating unnecessary copy operations. And third, by providing the compiler with more information as explained later in this section a lot of the overhead in PIC can be removed. This all combined will lead to overhead which is in most situations not noticeable.
并不总是需要使用%ebx，它可以帮助消除不必要的复制操作。第三，通过向编译器提供更多的信息，就像本节后面解释的那样，可以删除PIC中的大量开销。所有这些结合在一起将导致开销，在大多数情况下是不明显的。（有道翻译）

When gcc is used, the options -fpic/-fPIC also tell the compiler that a number of optimizations which are pos- sible for the executable cannot be performed. This has to do with symbol lookups and cutting it short. Since the compiler can assume the executable to be the first object in the lookup scope it knows that all references of global symbols known to be defined in the executable are re- solved locally. Access to locally defined variable could be done directly, without using indirect access through the GOT. This is not true for DSOs: the DSOs can be later in the lookup scope and earlier objects might be in- terposed. It is therefore mandatory to compile all code which can potentially end up in a DSO with -fpic/-fPIC since otherwise the DSO might not work correctly. There is no compiler option to separate this optimization from the generation of position-independent code.
当使用gcc时，选项-fpic/- fpic也告诉编译器许多可执行文件可能的优化不能执行。这与查找符号和缩短它有关。由于编译器可以假定可执行文件是查找范围中的第一个对象，因此它知道在可执行文件中定义的所有全局符号引用都是本地解析的。可以直接访问本地定义的变量，而不需要通过GOT进行间接访问。这对于DSOs来说不是这样的:DSOs可以在查找范围的后面，而较早的对象可能被插入。因此，必须编译所有可能以-fpic/ -fpic结尾的DSO代码，否则DSO可能无法正常工作。没有编译器选项可以将此优化与位置无关代码的生成分离。（有道翻译）