在Linux上创建.SO文件而不使用PIC（与位置无关的代码）（x86 32位）

据我所知，x86汇编代码在很大程度上受寄存器数量的限制。

当我了解到在Linux上要创建一个.so文件时，必须为gcc指定-fPIC命令行参数才能创建与位置无关的代码，我不敢首先相信它。

据我所知，elf文件格式支持重定位，就像-在我看来更好-Windows

DLL系统可以工作：在Windows上，链接器在DLL中重新定位所有偏移量（如果有必要）。

我认为加载SO文件或DLL文件所需的时间，以及用于保持不同位置重定位的.so文件所需的内存量，并不比始终缺少整个寄存器要糟糕。

GOT并具有所有这些间接跳转。

我也完全不在乎ALSR等。对于我所想到的应用程序，我只是在乎库中的代码要尽可能地优化。

1）为什么Linux不支持Windows这样的动态库加载，而动态库加载会产生更多性能代码？

到目前为止，我还没有找到真正的解释。只是这样的事情，代码的重新定位会非常糟糕且缓慢（当然，对于在台式机上加载文字处理器，它加载的速度非常重要，我完全接受。但是对于计算密集型的服务器进程（不处理来自互联网的恶意数据），我想拥有我所能获得的所有性能和寄存器！

2）我可以在Linux上创建NOT -fPIC编译的SO文件吗？我可以离开-

fPIC吗？是否有任何方法，手册或项目适用于该主题，并且可以避免浪费整个寄存器并仍然动态加载库？

如果仅在编译.so文件时放下-fPIC，会发生什么情况？

如果仅-fPIC在编译.so-file 时放下，会发生什么？

生成的共享库ELF文件（很有可能）将以半随机（即，不可预测的）页面地址动态加载（例如，因为mmapsyscall会遇到ASLR）。

链接器将产生大量的重定位操作。因此，动态链接程序（ld.so）必须缓慢处理大量重定位，因此必须重写您的文本段（并且不会与使用同一.so文件的其他进程有效地只读共享）。

因此，实际上-fPIC，即使有可能，忘记共享对象（即，动态链接库）上的链接通常也是一个坏主意。

阅读Drepper的HowTo做动态共享库的文章和Wheeler的程序库Howto

顺便说一句，与x86-64相比，在x86（32位）上与位置无关的代码成本更高。但是值得付出努力（在x86 32位上，PIC代码可能比非PIC慢5至10％）。