为什么fPIC绝对需要64位而不是32位平台？ [英] Why is fPIC absolutely necessary on 64 and not on 32bit platforms?
问题描述
我最近收到了一个：
...在制作共享对象时，不能使用针对本地符号的R_X86_64_32重定位;在尝试将程序编译为共享库时重新编译时带-fPIC
错误。
现在解决这个问题并不困难（用-fPIC重新编译所有依赖项），但经过一番研究后发现，这个问题只存在于x86-64平台上。在32位上，任何依赖位置的代码仍然可以通过动态加载器重新定位。
最好的 answer 我能找到的是：
x86支持.text重定位（当你有
位置相关代码时会发生什么）。这种支持需要付出代价，即包含这种重定位的每个
页面基本上都是不共享的，即使
位于共享库中，从而破坏了共享
libs的概念。因此，我们决定在amd64上不允许这样做（如果值超过32位，那么它会产生
问题，因为所有的.text relocs只有
的大小为'word32'）。
但是我觉得这不够。如果重定位破坏了共享库的概念，为什么它可以在32位平台上完成？另外，如果需要对ELF格式进行更改以支持64位，那么为什么并非所有的字段都增加以容纳？
这可能是小问题，但它的动机是：a）有问题的代码是一个科学代码，不用担心会有性能问题，而且b）这些信息在第一时间是不可能找到的！ / p>
<编辑：'答案'
@awoodlands answer 可能是最好的'文字回答'，@servn 加入一些很好的信息。
在搜索中可以找到更多关于不同类型重定位的信息，我发现这个，最终是一个 x86_64 ABI参考 （请参见第68页）
]
据我所知，问题是x86-64似乎引入了新的，相对于指令指针来说，引用数据的速度更快，而x86-32则不存在。 /code/c/amd64-pic.htmlrel =noreferrer>本文对其进行了深入分析，并给出了以下内容摘要：
x86-64使用指令指针相对偏移
到数据地址的能力是一个很好的优化，但是在共享库
的情况下，假设数据的相对位置无效
并且不能使用。在这种情况下，访问全局数据（即
任何可能在你身上改变的东西）必须经过一层
的抽象，即全局偏移表。
即， -fPIC 寻址为寻址增加了一个额外的抽象层，以使通常寻址方式中以前可能的（以及理想的特性）仍然适用于新的体系结构。 / p>
I recently received a:
...relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
error while trying to compile a program as a shared library.
Now the solution to this is not too difficult (recompile all dependencies with -fPIC), but after some research it turns out that this problem is only present on x86-64 platforms. On 32bit any position dependent code can still be relocated by the dynamic loader.
The best answer I could find is:
x86 has support for .text relocations (which is what happens when you have position-dependend code). This support comes at a cost, namely that every page containing such relocation becomes basically unshared, even if it sits in a shared library, thereby spoiling the very concept of shared libs. Hence we decided to disallow this on amd64 (plus it creates problems if the value needs more than 32bit, because all .text relocs only have size 'word32')
But I don't find this quite adequate. If it is the case that relocations spoil the concept of shared libraries, why can it be done on 32bit platforms? Also, if there were changes that needed to be made to the ELF format to support 64bit, then why were not all fields increased in size to accommodate?
This may be a minor point, but it is motivated by the fact that a) the code in question is a scientific code and it would be nice not to have to take a performance hit and b) this information was nye impossible to find in the first place!
[Edit: 'The Answer'
@awoodlands answer is probably the best 'literal answer', @servn added some good information.
In a search to find more about different types of relocations I found this and ultimately an x86_64 ABI reference (see page 68) ]
As I understand it the problem is x86-64 seems to introduce a new, faster way of referencing data relative to the instruction pointer, which did not exist for x86-32.
This article has a nice in-depth analysis of it, and gives the following executive summary:
The ability of x86-64 to use instruction-pointer relative offsetting to data addresses is a nice optimisation, but in a shared-library situation assumptions about the relative location of data are invalid and can not be used. In this case, access to global data (i.e. anything that might be changed around on you) must go through a layer of abstraction, namely the global offset table.
I.e. -fPIC addressing adds an extra layer of abstraction to addressing, to make what was previously possible (and a desirable feature) in the usual addressing style still work with the newer architecture.
这篇关于为什么fPIC绝对需要64位而不是32位平台？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
