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

Question

我正在调试一个特别奇怪的问题，在我的程序启动之前发生，即。这发生在代码开始在“_start”符号处执行之前的加载时间。是的，我正在手动修改ELF。没有迹象表明这是一种错误的ELF格式，我正在使用libelf进行修改，直到现在都非常成功。使用GDB，我可以在内存中看到.plt.got，.data（rw data）和.bss部分，并在“_start”地址（或由readelf返回的入口点地址）处放置一个断点。 plt.got和.data在我运行程序之前都看起来不错，然后我运行程序，我的.data部分以及.plt.got中的最后一个条目都被零删除掉了。它是.bss初始化到错误的地址，但.bss数据（几个全局变量）被正确加载。然后我也观察到，如果我改变.data的大小，它得到的地址块inited也会增长 - 它总是比我的.data部分大16bytes，而且如果我改变.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（消灭在它是execv@GLIBC_2.2.5的.got.plt中的最后一项）

及相关部分：

[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节，我看到在开始比.data段大0x606050 16字节块越来越设置为零 - 其中B TW覆盖我所有的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段新截面尺寸。那么困扰我的是什么？

1. 调试器，ddd，示出仿佛其加载在存储器中运行该程序之前的节目数据。此时没有任何内容被加载到内存中。 rw .data部分看起来好像在记忆中，而事实上它不是。

2. 一旦程序被运行之前它甚至开始在入口点（_start）执行时，rw .data部分似乎是zero'ed出来，或初始化为零，因为rw .data部分从未实际加载到内存中。

ddd是错过领先的，因为它突出了这款内存以表明它被改变，当-事实上，它始终为零。

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