在Linux上创建.SO文件而不使用PIC(位置无关代码)(x86 32位)

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了在Linux上创建.SO文件而不使用PIC(位置无关代码)(x86 32位)，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1608字，纯文字阅读大概需要3分钟。

内容图文

据我所知,x86汇编代码受到有限数量寄存器的限制.

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

据我所知,elf文件格式支持重定位,就像 – 在我眼中更好 – Windows DLL系统工作：在Windows上,链接器重定位DLL中的所有偏移,如果有必要的话.

我认为加载SO文件或DLL文件所需的时间,以及用于保存不同重定位的.so文件的内存量并不像缺少整个寄存器一样指向GOT并具有所有这些间接跳跃.

对于我想到的应用程序,我也根本不关心ALSR等.我只关心在库中尽可能地优化代码.

1)为什么Linux不支持更像Windows的动态库加载,它应该产生更高性能的代码？

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

2)我可以在Linux上创建NOT -fPIC编译的SO文件吗？我可以离开-fPIC吗？是否有关于此主题的howto,manual或project,并且可以不浪费整个寄存器并仍然动态加载库？

如果我在编译.so文件时丢弃-fPIC会发生什么？

解决方法:

What happens if I just drop the -fPIC when compiling a .so-file?

得到的共享对象ELF文件(很可能)将在半随机(即不可预测的)页面地址处动态加载(例如,因为mmap系统调用将遇到ASLR).

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

因此,在实践中,忘记共享对象(即动态链接库)上的-fPIC通常是一个坏主意,即使它是可能的.

阅读Drepper’s HowTo do Dynamic Shared Libraries论文和Wheeler的Program Library Howto

BTW,position independent code在x86(32位)上比在x86-64上成本高得多.但值得付出努力(可能,PIC代码在x86 32位上比非PIC低5到10％).

内容总结

以上是互联网集市为您收集整理的在Linux上创建.SO文件而不使用PIC(位置无关代码)(x86 32位)全部内容，希望文章能够帮你解决在Linux上创建.SO文件而不使用PIC(位置无关代码)(x86 32位)所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---