为什么从非 pic 对象创建的共享库可以工作？
我很困惑。我在 x86 上的 Linux 上尝试。
I'm confused. I try in Linux on x86.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我很困惑。我在 x86 上的 Linux 上尝试。
I'm confused. I try in Linux on x86.
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（2）
PIC 只是让加载程序变得更加简单，因为它只需要修改代码中的一些全局地址。非 PIC 代码仅包含更多这些地址，因此包含需要重定位的地址的表更大。但加载程序必须能够在任何一种情况下重新定位代码（例如，解析静态/全局变量和所有函数指针的地址）。
PIC just makes live more simple for the loader since it only has to modify a few global addresses in the code. Non-PIC code just contains a lot more of these addresses, so the table with addresses which need relocation are bigger. But the loader must be able to relocate the code in either case (for example, to resolve the addresses of static/global variables and all function pointers).
x86 ABI 类型支持共享库中的非 PIC 代码。正如之前指出的，这意味着通常共享的页面将不会被共享（因为 ld.so 需要修补代码中相当特殊的位置（GOT）中的引用）。
但以这种方式构建的库可能会快一点，因为 PIC 代码通常较慢。
amd64 ABI 不支持这一点。
x86 ABI kind of supports non-PIC code in shared libraries. As pointed out before it means pages that will normally be shared will not be shared (because ld.so needs to patch references in code rather special place (GOT)).
But libraries built that way may be a bit faster, because PIC code is generally slower.
amd64 ABI does not support that.