Question

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

使用GDB，我可以在内存中看到.plt.got，.data（rw数据）和.bss部分，并在＆＃34; _start＆＃34;地址（或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 16bytes大于.data部分设置为零 - BTW会覆盖我所有的rw数据。

Answer 1

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

您可能会对setting a watchpoint感兴趣，抓住将您的PLT条目归零的地方。

Answer 2

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

原来我的问题是我没有针对新版块尺寸调整rw LOAD细分。让我困惑的是什么？

调试器ddd显示程序数据，就好像它在程序运行之前加载到内存中一样。此时没有任何内容被加载到内存中。 rw .data部分看起来像是在记忆中并且在事实上并非如此。
程序运行后甚至在入口点（_start）开始执行之前，rw .data部分似乎已归零，或初始化为零因为rw .data部分从未实际加载到内存中。

ddd是错过领先的，因为它会突出显示此内存以表明它已被更改，而事实上它总是为零。

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

如何使用GDB调试加载器/链接器问题

2 个答案: