为什么用-fpic和-pie编译的程序会重定位Table？

Question

如果一个简单的程序是用下面的命令编译的：

arm-none-eabi-gcc -shared -fpic -pie --specs=nosys.specs simple.c -o simple.exe

并且使用命令打印重定位条目：

arm-none-eabi-readelf simple.exe -r

有一堆重定位条目部分（见下文）。

由于 -fpic / -pie 标志导致编译器生成与位置无关的 executable，我天真的（而且显然是错误的）假设是不需要重定位 table 因为加载程序可以毫无问题地将 executable 图像放置在任何地方。那么为什么那里有一个重定位 table，这是否表明代码实际上不是位置独立的？

Relocation section '.rel.dyn' at offset 0x82d4 contains 37 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
000084a8  00000017 R_ARM_RELATIVE   
000084d0  00000017 R_ARM_RELATIVE   
00008508  00000017 R_ARM_RELATIVE   
00008510  00000017 R_ARM_RELATIVE   
0000855c  00000017 R_ARM_RELATIVE   
00008560  00000017 R_ARM_RELATIVE   
00008564  00000017 R_ARM_RELATIVE   
00008678  00000017 R_ARM_RELATIVE   
0000867c  00000017 R_ARM_RELATIVE   
0000870c  00000017 R_ARM_RELATIVE   
00008710  00000017 R_ARM_RELATIVE   
00008714  00000017 R_ARM_RELATIVE   
00008718  00000017 R_ARM_RELATIVE   
00008978  00000017 R_ARM_RELATIVE   
000089dc  00000017 R_ARM_RELATIVE   
000089e0  00000017 R_ARM_RELATIVE   
00008abc  00000017 R_ARM_RELATIVE   
00008ae4  00000017 R_ARM_RELATIVE   
00018af4  00000017 R_ARM_RELATIVE   
00018af8  00000017 R_ARM_RELATIVE   
00018afc  00000017 R_ARM_RELATIVE   
00018c04  00000017 R_ARM_RELATIVE   
00018c08  00000017 R_ARM_RELATIVE   
00018c0c  00000017 R_ARM_RELATIVE   
00018c34  00000017 R_ARM_RELATIVE   
00019028  00000017 R_ARM_RELATIVE   
000084cc  00000c02 R_ARM_ABS32       00000000   __libc_fini
0000850c  00000602 R_ARM_ABS32       00000000   __deregister_frame_inf
00008558  00001302 R_ARM_ABS32       00000000   __register_frame_info
00008568  00001202 R_ARM_ABS32       00000000   _Jv_RegisterClasses
00008664  00000d02 R_ARM_ABS32       00000000   __stack
00008668  00000a02 R_ARM_ABS32       00000000   hardware_init_hook
0000866c  00000802 R_ARM_ABS32       00000000   software_init_hook
00008670  00000502 R_ARM_ABS32       0001902c   __bss_start__
00008674  00000702 R_ARM_ABS32       00019048   __bss_end__
0000897c  00001402 R_ARM_ABS32       00000000   free
00008ac0  00000402 R_ARM_ABS32       00000000   malloc

Relocation section '.rel.plt' at offset 0x83fc contains 4 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00018be8  00000416 R_ARM_JUMP_SLOT   00000000   malloc
00018bec  00000616 R_ARM_JUMP_SLOT   00000000   __deregister_frame_inf
00018bf0  00001316 R_ARM_JUMP_SLOT   00000000   __register_frame_info
00018bf4  00001416 R_ARM_JUMP_SLOT   00000000   free

Answer 1

一个 executable 由几个部分组成。虽然实际实施细节有所不同，但大致可分为四组：

Read-Only Executable代码，也称为"Text"
只读常量数据（全局常量）
（已初始化）读写数据（带初始值设定项的全局变量）
未初始化的读写数据（其他全局变量，初始化为0）

非位置无关代码包含大量对函数地址、全局变量和全局常量的引用。

只读数据和初始化读写数据有时包含对函数地址、全局变量和全局常量的引用：

int x;
int *y = &x; // y needs a relocation.

加载器可以根据重定位重定位代码，只有两个问题：

重定位在程序启动/库加载时需要时间
如果我们重新定位，我们现在在 RAM 中修改了文本段的 copy，这对于加载我们库的每个进程都是不同的，所以我们会浪费 RAM .

现在是真正的答案： PIC 旨在通过摆脱 text 重定位来解决上述问题，而不是摆脱所有重定位。

只读数据和初始化数据的重定位相对较少，所以（1.）和（2.）通常都不是问题。我们甚至不关心 (2.) 的读写数据，因为无论如何我们都需要为每个进程提供单独的副本。事实上，编译器没有办法使数据位置无关，因为如果你要求全局 int* y = &x; 那么编译器别无选择，只能将指针放在那里。

现在，如何使代码与位置无关？这取决于平台，但它通常涉及一些相对低效的操作，或者处理器对更有效的指令中使用的最大偏移量施加任意限制，以便以与位置无关的方式访问数据和代码。此外，动态链接意味着某些函数的地址甚至不被称为相对偏移量。因此，编译器倾向于使用包含实际地址的 table，代码将从 table 中查找实际地址。 tables，在不同平台上被称为 GOT、TOC、PLT 以及其他一些名称，很可能是具有大量重定位的常量数据。

如果无法避免搬迁，我们的想法是将它们全部放在一个地方，以尽量减少问题 (1.) 和 (2.)。

为什么用-fpic和-pie编译的程序会重定位Table？

Why does a Program Compiled with -fpic and -pie Have Relocation Table?

c

gcc

position-independent-code