1818IP-服务器技术教程,云服务器评测推荐,服务器系统排错处理,环境搭建,攻击防护等

当前位置:首页 - 运维 - 正文

君子好学,自强不息!

Linux addr2line具体应用指南

2022-11-08 | 运维 | gtxyzz | 637°c
A+ A-

调试zSeries上的Linux应用程序类似于调试其他体系结构上的Linux应用程序。对于有经验的Linux开发人员,最大的挑战是理解新的系统体系结构。对于刚接触Linux的大型机开发人员,掌握新的调试工具似乎是一项令人畏惧的任务。不要害怕。本文将提供Linux addr2line一些有用的提示来帮助您入门。

UserDebug日志记录

调试一个崩溃的程序的第一步是弄清哪里出了错。zSeries上的Linux内核具有这样一个内置特性,它在用户进程崩溃时记录一些基本的调试信息。要启用这个特性,请以root用户身份执行如下命令: echo1>>/proc/sys/kernel/userprocess_debug

当某个进程崩溃时,日志文件(/var/log/messages)中就会给出附加的信息,包括程序终止原因、故障地址,以及包含程序状态字(PSW)、通用寄存器和访问寄存器的简要寄存器转储。

Mar3111:34:28l02kernel:Userprocessfault:interruptioncode0x10 
Mar3111:34:28l02kernel:failingaddress:0 
Mar3111:34:28l02kernel:CPU:1 
Mar3111:34:28l02kernel:Processsimple(pid:30122,stackpage=05889000) 
Mar3111:34:28l02kernel: 
Mar3111:34:28l02kernel:UserPSW:070dc000c00ab738 
Mar3111:34:28l02kernel:task:05888000ksp:05889f08pt_regs:05889f68 
Mar3111:34:28l02kernel:UserGPRS:Mar3111:34:28l02kernel:00000000004019a0004019a000000000 
Mar3111:34:28l02kernel:00000003c00ab732004008f800400338 
Mar3111:34:28l02kernel:40018ffc0040061c40018e347ffff800 
Mar3111:34:28l02kernel:00400434804006248040066e7ffff800 
Mar3111:34:28l02kernel:UserACRS: 
Mar3111:34:28l02kernel:00000000000000000000000000000000 
Mar3111:34:28l02kernel:00000001000000000000000000000000 
Mar3111:34:28l02kernel:00000000000000000000000000000000 
Mar3111:34:28l02kernel:00000000000000000000000000000000 
Mar3111:34:28l02kernel:UserCode: 
Mar3111:34:28l02kernel:4440500007fea74a0001185418431835a8240000 

上面表明程序(名为“simple”)以一个程序中断代码0x10终止(操作系统原理表明这是一个段转换错误),而故障地址为0。毫无疑问,有人使用了空指针。现在我们知道发生了什么,下面需要弄清它发生在何处。

Linux addr2line基本的诊断

UserDebug日志条目所提供的信息可用于确定程序的崩溃位置。一些可用的工具可帮助解决您可能会遇到的各种程序终止问题。我们将在本文中逐步介绍那些工具。

首先,让我们检查一下该日志条目中的用户PSW。该PSW包含指令地址、状态码以及关于机器状态的其他信息。眼下,我们仅关心指令地址(第33至第63位)。为简化起见,让我们假设用户PSW是070dc00080400618。记住,我们是在考察一个ESA/390(31位寻址)PSW。第32位不是指令地址的一部分,它是指示31位寻址模式的标志,但是在研究PSW值时必须处理它。为了获得实际的指令指针,可把PSW的第二个字减去0x80000000。结果是一个指令地址0x400618。为了定位代码,您需要可执行文件中的一些信息。首先使用readelf来打印一些程序头信息。

ElffiletypeisEXEC(Executablefile)Entrypoint0x400474Thereare6programheaders,startingatoffset52ProgramHeaders: 
TypeOffsetVirtAddrPhysAddrFileSizMemSizFlgAlign 
PHDR0x0000340x004000340x004000340x000c00x000c0RE0x4 
INTERP0x0000f40x004000f40x004000f40x0000d0x0000dR0x1[Requestingprograminterpreter:/lib/ld.so.1] 
LOAD0x0000000x004000000x004000000x009900x00990RE0x1000 
LOAD0x0009900x004019900x004019900x000fc0x00114RW0x1000 
DYNAMIC0x0009ac0x004019ac0x004019ac0x000a00x000a0RW0x4 
NOTE0x0001040x004001040x004001040x000200x00020R0x4 
SectiontoSegmentmapping:SegmentSections... 
00 
01.interp 
02.interp.note.ABI-tag.hash.dynsym.dynstr.gnu.version 
.gnu.version_r.rela.got.rela.plt.init.plt.text.fini.rodata 
03.data.eh_frame.dynamic.ctors.dtors.got.bss 
04.dynamic 
05.note.ABI-tag 

上述显示了readelf-lsimple的结果(记住“simple”是我们的测试程序的名称)。在ProgramHeaders部分,第一个LOAD行提供了关于程序从哪里加载的信息。在Flg列,该段被标记为R(read)E(executable)。VirtAddr是程序开始加载的地址。MemSiz是正在被加载到这个段中的代码长度。把它加到VirtAddr上,这个程序的基本地址范围就是0x400000-0x400990。程序发生崩溃的指令地址为0x400618,在程序的加载范围之内。现在我们知道了问题直接发生在代码中。

如果可执行文件包括调试符号,那么确定哪一行代码导致了问题是可以做到的。对该地址和可执行文件使用addr2line程序,如下所示: addr2line-esimple0x400618

将返回: /home/devuser/simple.c:34

要研究该问题,可以检查第34行。

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

现在我们来确定Linux addr2line崩溃发生在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|grep0008a

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

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

将返回: /home/devuser/simple.c:36

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

本文来源:1818IP

本文地址:https://www.1818ip.com/post/7971.html

免责声明:本文由用户上传,如有侵权请联系删除!

发表评论

必填

选填

选填

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。