How To Write Shared Libraries(2)

1.1 A Little Bit of History

The binary format used initially for Linux was an a.out variant. When introducing shared libraries certain design decisions had to be made to work in the limitations of a.out. The main accepted limitation was that no reloca-tions are performed at the time of loading and afterward. The shared libraries have to exist in the form they are used at run-time on disk. This imposes a major restric-tion on the way shared libraries are built and used: every shared library must have a fixed load address; otherwise it would not be possible to generate shared libraries which do not have to be relocated.
linux系统中用于初始化的二进制格式是a.out的变体。
当介绍共享库的设计内容必然设计受限制的a.out。
最主要的限制是没有重加载的机制。
共享库不得不使用运行时的格式。
这样强制使用重定向机制:每个共享库必须有固定的加载地址;否则不能完成共享库的重载机制。

The fixed load addresses had to be assigned and this has to happen without overlaps and conflicts and with some future safety by allowing growth of the shared library. It is therefore necessary to have a central authority for the assignment of address ranges which in itself is a ma- jor problem. But it gets worse: given a Linux system of today with many hundred of DSOs (Dynamic Shared Objects) the address space and the virtual memory avail- able to the application gets severely fragmented. This would limit the size of memory blocks which can be dy- namically allocated which would create unsurmountable problems for some applications. It would even have hap- pened by today that the assignment authority ran out of address ranges to assign, at least on 32-bit machines.
固定地址必须设计防止将来覆盖和冲突。
因此一段自主地址空间成为主要问题。
更糟糕的是:现在linux有几百个共享库程序虚拟地址空间被分成许多段。
这将会限制动态申请内存块的大小,在一些应用上有无法解决的问题。
甚至有超出地址空间大小的情况,起码32位系统存储该问题。

We still have not covered all the drawbacks of the a.out shared libraries. Since the applications using shared li- braries should not have to be relinked after changing a shared library it uses, the entry points, i.e., the function and variable addresses, must not change. This can only be guaranteed if the entry points are kept separate from the actual code since otherwise limits on the size of a function would be hard-coded. A table of function stubs which call the actual implementation was the solution used on Linux. The static linker got the address of each function stub from a special file (with the filename ex- tension .sa). At run-time a file ending in .so.X.Y.Z was used and it had to correspond to the used .sa file. This in turn requires that an allocated entry in the stub table always had to be used for the same function. The allocation of the table had to be carefully taken care of. Introducing a new interface meant appending to the ta- ble. It was never possible to retire a table entry. To avoid using an old shared library with a program linked with a newer version, some record had to be kept in the applica- tion: the X and Y parts of the name of the .so.X.Y.Z suffix was recorded and the dynamic linker made sure minimum requirements were met.
这还不是所有问题。由于使用共享库的应用不会重新链接,共享库中函数和变量的地址不能由变化。只有保持入口地址不连续才能保证这个要求,否则很难编码。一个函数地址表用于解决该问题。静态连接器从一个特殊文件(.sa文件)获取函数的地址信息。运行时一个与.sa对应的.so.X.Y.Z的文件用于此实现。这要求获取地址表总是使用相同的函数。地址必须小心使用。添加接口意味着增加一个表项。不能再使用之前的表。为了阻止使用老的共享库版本,必须增加一些记录:X、Y是库的前缀,保证满足最小的要求。

The benefits of the scheme are that the resulting program runs very fast. Calling a function in such a shared li- braries is very efficient even for the first call. It can be implemented with only two absolute jumps: the first from the user code to the stub, and the second from the stub to the actual code of the function. This is probably faster than any other shared library implementation, but its speed comes at too high a price:
这样实现的优势是程序运行非常快。调用这样的函数即使第一次效率也很高。只要两个绝对地址的跳转就可以了:第一个从用户调用代码到地址表,第二个从地址表到实际功能函数。这基本比所有的共享库实现都高效,但代价太高:

  1. a central assignment of address ranges is needed;
    需要固定的地址分布。
  2. collisions are possible(likely)with catastrophic re-sults;
    可能的冲突导致灾难性的问题。
  3. the address space gets severely fragmented.
    地址空间非常分散。

For all these reasons and more, Linux converted early on to using ELF (Executable Linkage Format) as the binary format. The ELF format is defined by the generic spec-ification (gABI) to which processor-specific extensions (psABI) are added. As it turns out the amortized cost of function calls is almost the same as for a.out but the restrictions are gone.
由于这个或更多的原因,linux选择了ELF格式。ELF定义了一般的ABI处理肯能的ABI扩展。基于此,转移了调用的开销,取消了限制。

你可能感兴趣的:(How To Write Shared Libraries(2))