据我所知,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 时放下,会发生什么?
-fPIC
.so
生成的共享库ELF文件(很有可能)将以半随机(即,不可预测的)页面地址动态加载(例如,因为mmapsyscall会遇到ASLR)。
mmap
链接器将产生大量的重定位操作。因此,动态链接程序(ld.so)必须缓慢处理大量重定位,因此必须重写您的文本段(并且不会与使用同一.so文件的其他进程有效地只读共享)。
ld.so
因此,实际上-fPIC,即使有可能,忘记共享对象(即,动态链接库)上的链接通常也是一个坏主意。
阅读Drepper的HowTo做动态共享库的文章和Wheeler的程序库Howto
顺便说一句,与x86-64相比,在x86(32位)上与位置无关的代码成本更高。但是值得付出努力(在x86 32位上,PIC代码可能比非PIC慢5至10%)。