linker - R_X86_64_IRELATIV 是什么意思？

Question

我通过在 x86 arch 中静态链接 libc 库为一个简单程序构建了一个可执行文件。该可执行文件的重定位表如预期的那样为空:

$ readelf -r 测试
此文件中没有重定位。
$

当我为同一个程序构建一个可执行文件时，通过静态链接 libc 库，在 x86_64 arch 中，重定位表不为空:

$ readelf -r 测试

偏移量 0x1d8 处的重定位部分“.rela.plt”包含 12 个条目:

偏移信息类型符号。值(value)符号。名称 + 加号
0000006c2058 000000000025 R_X86_64_IRELATIV 000000000042de70
0000006c2050 000000000025 R_X86_64_IRELATIV 00000000004829d0
0000006c2048 000000000025 R_X86_64_IRELATIV 000000000042dfe0
0000006c2040 000000000025 R_X86_64_IRELATIV 000000000040a330
0000006c2038 000000000025 R_X86_64_IRELATIV 0000000000432520
0000006c2030 000000000025 R_X86_64_IRELATIV 0000000000409ef0
0000006c2028 000000000025 R_X86_64_IRELATIV 0000000000445ca0
0000006c2020 000000000025 R_X86_64_IRELATIV 0000000000437f40
0000006c2018 000000000025 R_X86_64_IRELATIV 00000000004323b0
0000006c2010 000000000025 R_X86_64_IRELATIV 0000000000430540
0000006c2008 000000000025 R_X86_64_IRELATIV 0000000000430210
0000006c2000 000000000025 R_X86_64_IRELATIV 0000000000432400
$

我用谷歌搜索了重定位类型“R_X86_64_IRELATIV”，但我可以找到有关它的任何信息。所以有人可以告诉我这是什么意思吗？

我想如果我用 gdb 调试可执行文件，我可能会找到答案。但实际上它带来了很多问题:) 以下是我的分析:

上表中的 Sym.Name 字段列出了一些 libc 函数的虚拟地址。当我 objdump 可执行 'test' 时，我发现虚拟地址 0x430210 包含 strcpy 函数。在加载在位置 0x6c2008 找到的相应 PLT 条目时，它从 0x400326(下一条指令的虚拟地址，即设置解析器)更改为 0x0x443cc0(名为 __strcpy_sse2_unaligned 的 libc 函数的虚拟地址)我不知道为什么它会解析为不同的函数而不是strcpy？我假设它是 strcpy 的不同变体。

完成此分析后，我意识到我错过了前面的基本点“加载静态可执行文件时，动态链接器为什么会出现？”我没有找到 .interp 部分，因此肯定不涉及动态链接器。然后我观察到，一个 libc 函数“__libc_csu_irel()”修改了 PLT 条目而不是动态链接器。

如果我的分析对任何人更有意义，请让我知道这一切。我很乐意知道其背后的原因。

非常感谢!!!

Answer 1

TL; 博士
你是对的。那些重定位只是试图找出应该使用(不仅是)libc 函数的什么实现。它们在 main 之前解决了由函数 __libc_start_main 执行在链接时插入二进制文件。

我将尝试解释这种重定位类型是如何工作的。
这个例子
我正在使用此代码作为引用

//test.c
#include <stdio.h>
#include <string.h>

int main(void)
{
    char tmp[10];
    char target[10];
    fgets(tmp, 10, stdin);
    strcpy(target, tmp);
}

使用 GCC 7.3.1 编译

gcc -O0 -g -no-pie -fno-pie -o test -static test.c

重定位表的缩短输出( readelf -r test ):

Relocation section '.rela.plt' at offset 0x1d8 contains 21 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
...
00000069bfd8  000000000025 R_X86_64_IRELATIV                    415fe0
00000069c018  000000000025 R_X86_64_IRELATIV                    416060

节标题的缩短输出( readelf -S test ):

[Nr] Name              Type             Address           Offset
     Size              EntSize          Flags  Link  Info  Align
...
[19] .got.plt          PROGBITS         000000000069c000  0009c000
     0000000000000020  0000000000000008  WA       0     0     8
...

它说 .got.plt部分在地址 0x69c000 .
R_X86_64_IRELATIV 重定位是如何解决的
重定位表中的每条记录都包含偏移量和加数两个重要信息。换句话说，加数是指向函数的指针(也称为间接函数)，它不带参数并返回指向函数的指针。返回的指针放置在重定位记录的偏移量上。
简单的重定位解析器实现:

void reolve_reloc(uintptr_t* offset, void* (*addend)())
{
    //addend is pointer to function
    *offset = addend();
}

来自本答案开头的示例。重定位表中的最后一个加数指向地址 0x416060这是函数 strcpy_ifunc .查看反汇编的输出:

0000000000416060 <strcpy_ifunc>:
  416060:       f6 05 05 8d 28 00 10    testb  $0x10,0x288d05(%rip)        # 69ed6c <_dl_x86_cpu_features+0x4c>
  416067:       75 27                   jne    416090 <strcpy_ifunc+0x30>
  416069:       f6 05 c1 8c 28 00 02    testb  $0x2,0x288cc1(%rip)        # 69ed31 <_dl_x86_cpu_features+0x11>
  416070:       75 0e                   jne    416080 <strcpy_ifunc+0x20>
  416072:       48 c7 c0 70 dd 42 00    mov    $0x42dd70,%rax
  416079:       c3                      retq   
  41607a:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)
  416080:       48 c7 c0 30 df 42 00    mov    $0x42df30,%rax
  416087:       c3                      retq   
  416088:       0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
  41608f:       00 
  416090:       48 c7 c0 f0 0e 43 00    mov    $0x430ef0,%rax
  416097:       c3                      retq   
  416098:       0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
  41609f:       00 

strcpy_ifunc选择最好的选择 strcpy实现 an 返回指针。就我而言，它返回地址 0x430ef0这是 __strcpy_sse2_unaligned .这个地址是十放在 0x69c018这是在 .glob.plt + 0x18谁和何时解决它
通常重新分配的第一个想法是所有这些东西都处理动态解释器( ldd )。但在这种情况下，程序是静态链接的， .interp部分是空的。在这种情况下，它在函数 __libc_start_main 中解析这是 GLIBC 的一部分。除了解决重定位这个函数还负责将命令行参数传递给您的 main并做一些其他的事情。
访问重定位表
当我弄清楚时，我有最后一个问题，如何 __libc_start_main访问保存在 ELF header 中的重定位表？第一个想法是它以某种方式打开正在运行的二进制文件以进行读取和处理。当然，这是完全错误的。如果您查看可执行文件的程序头，您会看到类似这样的内容 ( readlef -l test ):

Type           Offset             VirtAddr           PhysAddr
               FileSiz            MemSiz              Flags  Align
LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
               0x0000000000098451 0x0000000000098451  R E    0x200000
...

此 header 中的偏移量是从可执行文件的第一个字节开始的偏移量。所以程序头中的第一项是复制 test 的前 0x98451 个字节。文件存入内存。但是在偏移量 0x0 上是 ELF header 。因此，对于代码段，它还会将 ELF header 加载到内存和 __libc_start_main 中。可以轻松访问它。