Linux debug : addr2line追踪出错地址(2)

对于图1中原始的程序崩溃,PSW 为070dc000 c00ab738。要获得指令地址,可减去0x80000000。结果为0x400ab738。这个地址并不准确地落在我们的小程序之内。那么,它是什么呢?是来自共享库的代码。如果对可执行文件运行ldd 命令(ldd simple),将会返回程序运行所需的共享对象的列表,以及该库在那里可用的地址。

libc.so.6 => /lib/libc.so.6 (0x40021000) /lib/ld.so.1 => /lib/ld.so.1 (0x40000000)  

该指令地址对应于加载libc.so.6的地址。在我们的简单测试案例中,只需要两个共享对象。其他应用程序可能需要更多共享对象,这使得ldd的输出更加复杂。我们将以perl作为例子。 输入:

ldd /usr/bin/perl  

将得到:

libnsl.so.1 => /lib/libnsl.so.1 (0x40021000) libdl.so.2 => /lib/libdl.so.2 (0x40039000) libm.so.6 => /lib/libm.so.6 (0x4003d000) libc.so.6 => /lib/libc.so.6 (0x40064000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4018f000) /lib/ld.so.1 => /lib/ld.so.1 (0x40000000)  

所需要的一切都在那里了,但是我发现对于这个进程,下面的内容读起来更快一点:

ldd /usr/bin/perl | awk ‘{print? $4 “ “ $3 }’ | sort (0x40000000) /lib/ld.so.1 (0x40021000) /lib/libnsl.so.1 (0x40039000) /lib/libdl.so.2 (0x4003d000) /lib/libm.so.6 (0x40064000) /lib/libc.so.6 (0x4018f000) /lib/libcrypt.so.1  

现在我们来确定崩溃发生在libc中的何处。假设libc.so.6的加载地址是0x40021000,从指令地址 0x400ab738减去它,结果为0x8a738。这是进入libc.so.6 的偏移。使用nm命令,从libc.so.6转储符号,然后尝试确定该地址位于哪个函数中。对于libc.so.6,nm将生成7,000多行输出。通过对计算得出的偏移部分执行 grep(正则表达式查找程序)可以削减必须检查的数据量。输入:

nm /lib/libc.so.6 | sort | grep 0008a  

将返回 66 行,在该输出的中间,我们会发现:

0008a6fc T memcpy 0008a754 t _wordcopy_fwd_aligned  

该偏移落在memcpy中的某个位置。在此例中,一个空指针被当作目标地址传递给了memcpy。我们在何处调用的memcpy呢?问得好。我们可以通过检查输出在日志文件中的寄存器转储来确定目标区域。寄存器14包含执行某个函数调用时的返回地址。根据图1,R14是0x8040066e,它在截去高位之后产生一个地址 0x40066e。这个地址落在我们的程序范围之内,因此可以运行addr2line来确定该地址在何处。输入:

addr2line -e simple 0x40066e  

将返回:

/home/devuser/simple.c:36  

这是我们调用memcpy之后的那一行。关于addr2line的一点补充:如果可执行文件中没有包括调试符号,您将获得??:0 作为响应。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wwfpgj.html