嵌入式Arm程序通过core文件找到dump位置

一 编译带调试信息的程序

二 配置core文件参数

1)查看当前系统限制情况

ulimit -a

2)设置crash dump文件大小

ulimit -c unlimited
unlimited表示无大小限制，也可以指定具体的大小
ulimit -c 1000
表示文件大小限制为1000Kb
若要全局生效需要在/etc/profile中加入上面的命令ulimit -c 1000,然后source /etc/profile使之生效

3) 配置dump文件生成路径

/proc/sys/kernel/core_uses_pid
文件内容为1表示dump文件以pid为扩展名
/proc/sys/kernel/core_pattern
core_pattern接受的是core文件名称的pattern，它包含任何字符串，并且用%作为转移符号生成一些标示符，为core文件名称加入特殊含义。已定义的标示符有如下这些：
%%：相当于%
%p：相当于pid
%u：相当于uid
%g：相当于gid
%s：相当于导致dump的信号的数字
%t：相当于dump的时间
%e：相当于执行文件的名称
%h：相当于hostname
除以上这些标志位外，还规定：
1、末尾的单个%可以直接去除；
2、%加上除上述以外的任何字符，%和该字符都会被去除；
3、所有其他字符都作为一般字符加入名称中；
4、core文件的名称最大值为64个字节（包括’\0’）；
5、core_pattern中默认的pattern为core；
6、为了保持兼容性，通过设置core_uses_pid，可以在core文件的末尾加上%p；
7、pattern中可以包含路径信息。
echo “/corefile/core-%e-%p-%t” > /proc/sys/kernel/core_pattern
将会控制所产生的core文件会存放到/corefile目录下(/corefile目录需要提前创建)，产生的文件名为core-执行文件名-pid-时间戳

在发生SIGSEGV时系统会自动在程序目录下生成core.xxxx文件，此即dump文件；
注意，此时程序不能再注册SIGSEGV的处理函数！

三 使用gdb分析dump文件

1)使用arm-linux-gdb 载入arm开发板生成的core

把生成的core文件拷贝到与可执行文件同一个目录下

执行 gdb a.out core.xxx

2）使用GDB命令调试

2.1 使用where 或bt命令，将显示#x这样的堆栈信息

2.2 使用frame x，能查看更详细的函数调用信息：frame x，x为#后的数字

四 使用maps查看crash的函数名

运行着个程序发生了crash，并且生成了core文件，

./sample_main

Segmentation fault (core dumped)

通过gdb+core看到了crash的地址

GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/nap/sample_main...(no debugging symbols found)...done.
[New LWP 4170]

warning: Can't read pathname for load map: Input/output error.
Core was generated by `./sample_main'.
Program terminated with signal 11, Segmentation fault.
#0  0xb773a478 in ???
(gdb) bt
#0  0xb773a478 in ???
#1  0x08048770 in ???
#2  0x08048763 in ???
(gdb)

通过查看进程的map可以看出crash的位置在libsample_fun.so的代码段，

08048000-08049000 r-xp 00000000 08:05 1059318    /home/nap/sample_main
08049000-0804a000 r--p 00000000 08:05 1059318    /home/nap/sample_main
0804a000-0804b000 rw-p 00001000 08:05 1059318    /home/nap/sample_main
b7449000-b744b000 rw-p 00000000 00:00 0
b744b000-b7467000 r-xp 00000000 08:05 1311741    /lib/i386-linux-gnu/libgcc_s.so.1
b7467000-b7468000 r--p 0001b000 08:05 1311741    /lib/i386-linux-gnu/libgcc_s.so.1
b7468000-b7469000 rw-p 0001c000 08:05 1311741    /lib/i386-linux-gnu/libgcc_s.so.1
b7469000-b7493000 r-xp 00000000 08:05 1315013    /lib/i386-linux-gnu/libm-2.15.so
b7493000-b7494000 r--p 00029000 08:05 1315013    /lib/i386-linux-gnu/libm-2.15.so
b7494000-b7495000 rw-p 0002a000 08:05 1315013    /lib/i386-linux-gnu/libm-2.15.so
b7495000-b7638000 r-xp 00000000 08:05 1310845    /lib/i386-linux-gnu/libc-2.15.so
b7638000-b763a000 r--p 001a3000 08:05 1310845    /lib/i386-linux-gnu/libc-2.15.so
b763a000-b763b000 rw-p 001a5000 08:05 1310845    /lib/i386-linux-gnu/libc-2.15.so
b763b000-b763f000 rw-p 00000000 00:00 0
b763f000-b7717000 r-xp 00000000 08:05 1575071    /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16
b7717000-b7718000 ---p 000d8000 08:05 1575071    /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16
b7718000-b771c000 r--p 000d8000 08:05 1575071    /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16
b771c000-b771d000 rw-p 000dc000 08:05 1575071    /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16
b771d000-b7724000 rw-p 00000000 00:00 0
b773a000-b773b000 r-xp 00000000 08:05 1059319    /home/nap/libsample_fun.so
b773b000-b773c000 r--p 00000000 08:05 1059319    /home/nap/libsample_fun.so
b773c000-b773d000 rw-p 00001000 08:05 1059319    /home/nap/libsample_fun.so
b773d000-b773f000 rw-p 00000000 00:00 0
b773f000-b7740000 r-xp 00000000 00:00 0          [vdso]
b7740000-b7760000 r-xp 00000000 08:05 1311879    /lib/i386-linux-gnu/ld-2.15.so
b7760000-b7761000 r--p 0001f000 08:05 1311879    /lib/i386-linux-gnu/ld-2.15.so
b7761000-b7762000 rw-p 00020000 08:05 1311879    /lib/i386-linux-gnu/ld-2.15.so
bf97d000-bf99e000 rw-p 00000000 00:00 0          [stack]

接下来我们要求出crash的函数在libsample_fun.so中的地址，计算方式如下

发生crash的地址 - 动态库的起始地址 + 偏移地址

在我们的例子中为0xb773a478 - 0xb773a000 + 0x00000000 = 0x478

通过 nm -n libsample_fun.so将这个动态库中的符号表按地址顺序输出

nap@nap-HP-431-Notebook-PC:~$ nm -n libsample_fun.so
         w _Jv_RegisterClasses
         w __cxa_finalize@@GLIBC_2.1.3
         w __gmon_start__
         U printf@@GLIBC_2.0
00000330 T _init
000003a0 t __do_global_dtors_aux
00000420 t frame_dummy
00000457 t __i686.get_pc_thunk.bx
0000045c T _Z8testFun4v
000004a0 t __do_global_ctors_aux
000004d8 T _fini
00000574 r __FRAME_END__
00001f14 d __CTOR_LIST__
00001f18 d __CTOR_END__
00001f1c d __DTOR_LIST__
00001f20 d __DTOR_END__
00001f24 d __JCR_END__
00001f24 d __JCR_LIST__
00001f28 a _DYNAMIC
00001ff4 a _GLOBAL_OFFSET_TABLE_
0000200c d __dso_handle
00002010 A __bss_start
00002010 A _edata
00002010 b completed.6159
00002014 b dtor_idx.6161
00002018 A _end

找到最接近0x478且比0x478下的地址，这个地址的函数就是发生crash的函数

使用c++filt将这个函数名打印出来

nap@nap-HP-431-Notebook-PC:~$ c++filt _Z8testFun4v
testFun4()

这样我们就找到了crash的函数。

五 set solib-search-path he set solib-absolute-prefix区别

solib-absolute-prefix 和solib-search-path是 gdb比较常用的选项，用来设置符号文件的位置。

那么，它们有什么区别呢？

solib-absolute-prefix设置的是被搜索文件路径的前缀，solib-search-path设置的是被搜索文件的路径。

solib-search-path可以有多个路径，中间按用:隔开， solib-absolute-prefix的值只能有一个。

下面以一个例子说明。

先载入一个 core dump文件：

    (gdb) core-file core
    [New LWP 489]
    warning: Could not load shared library symbols for 2 libraries, e.g. /mnt/libshared.so.
    Use the "info sharedlibrary" command to see the complete listing.
    Do you need "set solib-search-path" or "set sysroot"?
    Core was generated by `./main'.
    Program terminated with signal 11, Segmentation fault.
    #0  0x2ac02508 in ?? ()

先执行下 info sharedlibrary:

    (gdb) info sharedlibrary
    From        To          Syms Read   Shared Object Library
                            No          /mnt/libshared.so
                            No          /lib/libc.so.6
    0x2ab417e0  0x2ab52bf0  Yes (*)     /home/charles/code/gcc-arm-2012.04-linux/arm-linux-gnueabi/libc/lib/ld-linux.so.3
    (*): Shared library is missing debugging information.

有两个动态库还没有载入。

假设当前目录下有文件 libshared.so, 可以执行下面的命令：

    (gdb) set solib-search-path .
    Reading symbols from /home/charles/libshared.so...done.
    Loaded symbols for /home/charles/libshared.so

再看下动态库的加载情况：

    (gdb) info sharedlibrary
    From        To          Syms Read   Shared Object Library
    0x2ac0240c  0x2ac02510  Yes         /home/charles/libshared.so
                            No          /lib/libc.so.6
    0x2ab417e0  0x2ab52bf0  Yes (*)     /home/charles/code/gcc-arm-2012.04-linux/arm-linux-gnueabi/libc/lib/ld-linux.so.3
    (*): Shared library is missing debugging information.

还有一个没有载入。

假设文件 libc.so.6在 /media/DATA/lib/libc.so.6下：

    ~$ ls /media/DATA/lib/ -l
    total 860
    -rw------- 1 charles charles 876656 Nov 18 03:56 libc.so.6

这时，可以用 solib-absolute-path。

    (gdb) set solib-absolute-prefix /media/DATA
    Reading symbols from /media/DATA/lib/libc.so.6...(no debugging symbols found)...done.
    Loaded symbols for /media/DATA/lib/libc.so.6

这时，gdb用前缀 /media/DATA + /lib/libc.so.6,就找到了文件。

 /lib 是可执行文件在 目标机上  link libc.so.6的位置。

    (gdb) bt full
    #0  0x2ac02508 in fun () at testsharedlib.c:3
    No locals.
    #1  0x00008570 in main () at main.c:6
    No locals.
    (gdb) l *0x2ac02508
    0x2ac02508 is in fun (testsharedlib.c:3).
    1    void fun(void)
    2    {
    3        *(int *)0 = 0;
    4    }