使用gdb分析coredump文件和远程调试

 

本文介绍如何使用gdb分析coredump文件和远程调试，尤其是当出现段错误时，可以很快找出是哪段代码导致出错。

 

1. 产生coredump，使用gdb分析

首先，你所用的linux要支持coredump输出，有些定制的linux由于捕获coredump信号后另作处理，所以产生不了coredump

其次，指定允许的coredump文件大小， 一般设为： ulimit -c unlimited

1.1 查看进程的/proc/pid/smap信息

00400000-009b8000 r-xp 00000000 00:0c 5652535    /usr/local/esw/hal/toph
009c7000-00ebb000 rw-p 005b7000 00:0c 5652535    /usr/local/esw/hal/toph
00ebb000-01656000 rwxp 00000000 00:00 0          [heap]

2ace8000-2adf2000 r-xp 00000000 00:0c 5669039    /usr/local/esw/lib/libtophsl.so.1 // 可读，可执行，一看就是代码段
2adf2000-2ae02000 ---p 0010a000 00:0c 5669039    /usr/local/esw/lib/libtophsl.so.1  //这是什么段？？？
2ae02000-2ae04000 rw-p 0010a000 00:0c 5669039    /usr/local/esw/lib/libtophsl.so.1 // 可读可写, 数据段

7f9e2000-7f9ff000 rwxp 00000000 00:00 0          [stack]
7fff7000-7fff8000 r-xp 00000000 00:00 0          [vdso]

 

1.2 用gdb分析coredump文件
#2 <signal handler called>
#3 0x2b346054 in memset () from /vobs/etos/toolchains/mips_wrs_linux-2.6.34.8_libc_2.11.1/sysroot/lib/libc.so.6
#4 0x2ad01530 in Tophsl__DeleteAtmLinkTable (mAtmLinkTable=..., wAtmLink=<value optimized out>)
    at /vobs/etos/on_product/oms1400/hal/tdmopkt/oms/common/tophsl.c:11841
#5 0x0041cb20 in Toph__DeleteAtmLinkTable (pMsg=0x1164302) at generated/toph.c:3925

注意：

如果使用了共享库就要在gdb里设置库的路径，否则会提示找不到lib库，无法解析，那就不好找不出那个文件哪一行出问题了。

set sysroot /vobs/etos/toolchains/mips_wrs_linux-2.6.34.8_libc_2.11.1/sysroot                              指定所用的linux标准lib库
set solib-search-path /vobs/etos/on_product/oms1400/oms-1410/build-atm/exa_libs/                  指定搜索lib库的路径

 

1.3 使用反汇编验证步骤2的结论，更有技术含量哦

0x2ad01530-2ace8000=， 在libtophsl.so.1的反汇编里可以找到这个代码段偏移量对应的是那行代码，就能找到是哪行出错了。直接用gdb分析core-dump文件，可以更容易，直观的看到是哪一行出错了，如上面红色部分标出的tophsl.c:11841，这与前面我们手工计算偏移得出的是同一个地方。

objdump -DS  libtophsl.so.1

2. gdb远程单步调试

 

2.1 在目标板运行

gdbserver 147.128.17.139:6767 --attach 128           在目标板上运行gdbserver，指定远程主机IP和所用端口，及要调试的进程ID

 

2.1 在远程主机上运行

gdb target remote 10.170.80.21:6767 toph  在远程主机上运行gdb client端，指定目标板IP和所用端口，及要调试的进程文件名及路径

c 运行