2

我正在调试在我的程序启动之前发生的一个特别奇怪的问题，即。这发生在代码在“_start”符号处开始执行之前的加载时间。是的，我正在手动修改 ELF。没有迹象表明 ELF 格式不好，我正在使用 libelf 进行修改，并且到目前为止一直非常成功。

使用 GDB，我可以看到内存中的 .plt.got、.data（rw 数据）和 .bss 部分，并在“_start”地址（或 readelf 返回的入口点地址）处放置一个断点。.plt.got 和在我运行程序之前，.data 看起来都很好。然后我运行程序，我的 .data 部分以及 .plt.got 中的最后一个条目都被零清除了。

最初我以为是 .bss 初始化到了错误的地址，但正确加载了 .bss 数据（几个全局变量）。然后我还观察到，如果我改变 .data 的大小，它被初始化的地址块也会增长 - 它总是比我的 .data 部分的大小大 16 字节，如果我改变它不会增长.bss 部分大小。

我该如何调试呢？GDB 不会让我拦截或向运行时加载的库添加断点（或者我不知道如何），而且我确信加载器/链接器用作初始化某些数据的基础可能有一些数据出错记忆。

我还在寻找一些指向默认 std gnuc 东西的指针，这些东西在加载/链接时运行并执行一些初始化，以及该块中的哪些进程执行程序页面中数据的初始化，特别是任何会关闭大小的东西.data 部分。

以下是一些相关数据：

$ ld --version
GNU ld version 2.26.20160125

gcc --version
gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)


Relocation section '.rela.plt' at offset 0x870 contains 24 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000605f98  000100000007 R_X86_64_JUMP_SLO 0000000000000000 getenv@GLIBC_2.2.5 + 0
000000605fa0  000200000007 R_X86_64_JUMP_SLO 0000000000000000 free@GLIBC_2.2.5 + 0
000000605fa8  000300000007 R_X86_64_JUMP_SLO 0000000000000000 putchar@GLIBC_2.2.5 + 0
000000605fb0  000400000007 R_X86_64_JUMP_SLO 0000000000000000 __errno_location@GLIBC_2.2.5 + 0
000000605fb8  000500000007 R_X86_64_JUMP_SLO 0000000000000000 strncmp@GLIBC_2.2.5 + 0
000000605fc0  000600000007 R_X86_64_JUMP_SLO 0000000000000000 puts@GLIBC_2.2.5 + 0
000000605fc8  000700000007 R_X86_64_JUMP_SLO 0000000000000000 readlink@GLIBC_2.2.5 + 0
000000605fd0  000800000007 R_X86_64_JUMP_SLO 0000000000000000 __mempcpy@GLIBC_2.2.5 + 0
000000605fd8  000900000007 R_X86_64_JUMP_SLO 0000000000000000 textdomain@GLIBC_2.2.5 + 0
000000605fe0  000a00000007 R_X86_64_JUMP_SLO 0000000000000000 pathconf@GLIBC_2.2.5 + 0
000000605fe8  000b00000007 R_X86_64_JUMP_SLO 0000000000000000 dcgettext@GLIBC_2.2.5 + 0
000000605ff0  000c00000007 R_X86_64_JUMP_SLO 0000000000000000 printf@GLIBC_2.2.5 + 0
000000605ff8  000d00000007 R_X86_64_JUMP_SLO 0000000000000000 __libc_start_main@GLIBC_2.2.5 + 0
000000606000  000e00000007 R_X86_64_JUMP_SLO 0000000000000000 strcmp@GLIBC_2.2.5 + 0
000000606008  000f00000007 R_X86_64_JUMP_SLO 0000000000000000 __dcgettext@GLIBC_2.2.5 + 0
000000606010  001000000007 R_X86_64_JUMP_SLO 0000000000000000 fprintf@GLIBC_2.2.5 + 0
000000606018  001200000007 R_X86_64_JUMP_SLO 0000000000000000 memcpy@GLIBC_2.14 + 0
000000606020  001300000007 R_X86_64_JUMP_SLO 0000000000000000 malloc@GLIBC_2.2.5 + 0
000000606028  001400000007 R_X86_64_JUMP_SLO 0000000000000000 confstr@GLIBC_2.2.5 + 0
000000606030  001500000007 R_X86_64_JUMP_SLO 0000000000000000 setlocale@GLIBC_2.2.5 + 0
000000606038  001600000007 R_X86_64_JUMP_SLO 0000000000000000 error@GLIBC_2.2.5 + 0
000000606040  001700000007 R_X86_64_JUMP_SLO 0000000000000000 sysconf@GLIBC_2.2.5 + 0
000000606048  001800000007 R_X86_64_JUMP_SLO 0000000000000000 exit@GLIBC_2.2.5 + 0
000000606050  001900000007 R_X86_64_JUMP_SLO 0000000000000000 execv@GLIBC_2.2.5 + 0

初始化从 0x606050 开始（清除 .got.plt 中的最后一个条目，即 execv@GLIBC_2.2.5）

以及相关部分：

  [25] .got.plt          PROGBITS         0000000000605f80  00005f80
       00000000000000d8  0000000000000008  WA       0     0     8
  [26] .data             PROGBITS         0000000000606058  00006058
       0000000000000040  0000000000000000  WA       0     0     1
  [27] .bss              NOBITS           00000000006060e0  00006098
       0000000000000030  0000000000000000  WA       0     0     32

请注意，无论我制作的 .data 部分多么大，我都看到一个从 0x606050 开始的块，比 .data 部分大 16 字节被设置为零 - 顺便说一句，它会覆盖我所有的 rw 数据。

4

2 回答 2

4

您可以直接调用 ld.so：参见man 8 ld.so。这将允许您通过 gdb 调试动态链接器的行为。您可以通过其包管理器获取您的发行版 ld.so 的调试符号和源代码。否则，您可能有兴趣为此目的从源代码构建它。（必须调试动态链接器是非常不寻常的。）

您可能有兴趣设置一个观察点来捕捉将您的 PLT 条目归零的位置。

于 2017-03-27T21:41:27.257 回答
2

发现此链接对如何调试加载器很有用：https ://sourceware.org/glibc/wiki/Debugging/Loader_Debugging

原来我的问题是我没有rw LOAD为新的部分大小调整我的部分。那么让我困惑的是什么？

  1. 调试器ddd显示程序数据，就好像它在程序运行之前加载到内存中一样。此时没有任何内容加载到内存中。该rw .data部分看起来像是在内存中，并且实际上它不是正确的。

  2. 一旦程序运行并且在入口点_start（rw .datarw .data

ddd是错误的，因为它突出显示此内存以指示它已更改，而实际上它始终为零。

调试器在实际加载到内存之前显示程序数据时ddd也必须忽略段大小。LOAD

于 2017-04-18T01:07:48.227 回答