gpt4 book ai didi

c - 为什么用-fpic和-pie编译的程序会有重定位表?

转载 作者:太空狗 更新时间:2023-10-29 15:40:14 28 4
gpt4 key购买 nike

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

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

重定位条目使用以下命令打印:

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

有一堆重定位条目部分(见下文)。

由于 -fpic/-pie 标志导致编译器生成与位置无关的可执行文件,我天真的(而且显然是不正确的)假设是不需要重定位表,因为加载程序可以毫无问题地将可执行镜像放置在任何地方。那么为什么那里有一个重定位表,这是否表明代码实际上不是位置独立的?

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

最佳答案

一个可执行文件由几个部分组成。虽然实际的实现细节有所不同,但大致可以分为四组:

  1. 只读可执行代码,也称为“文本”
  2. 只读常量数据(全局常量)
  3. (已初始化)读写数据(带初始值设定项的全局变量)
  4. 未初始化的读写数据(其他全局变量,初始化为0)

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

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

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

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

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

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

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

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

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

关于c - 为什么用-fpic和-pie编译的程序会有重定位表?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37198441/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com