嵌入式core dump调试方法

 一、为什么使用coredump

有的时候写的程序总会遇到各种异常或者bug导致退出中止，但是程序却没有打印出可供参考的log信息，这时候就可以利用code文件进行分析。一般情况下，code文件会记录程序运行的内存，寄存器，堆栈指针等信息，想要使用code文件分析，就需要在linux系统中设置一下。

二、嵌入式下coredump生成设置

1.一般linux系统下默认是不会生成core dump文件的（毕竟生成的文件还是蛮大的），通过ulimit –a （如下图所示）可以查看能生成的code文件的大小，一般是0。可以通过“ulimit –c 参数（blocks）”或者“ulimit –c unlimited”设置，建议用后者。

 

 

2.设置core dump文件的输出位置，一般默认是当前目录，可以通过“echo “1” > /proc/sys/kernel/core_uses_pid ”使core文件加上pid号，也可以用“echo ”core保存目录/core-%e-%p-%t“ > /proc/sys/kernel/core_pattern ” 设置。

以下是参数表：ps：用到的也就那么几个

%p – insert pid into filename 添加pid

%u – insert current uid into filename 添加当前uid

%g – insert current gid into filename 添加当前gid

%s – insert signal that caused the coredump into the filename 添加导致产生core的信号

%t – insert UNIX time that the coredump occurred into filename 添加core文件生成时的unix时间

%h – insert hostname where the coredump happened into filename 添加主机名

%e – insert coreddumping executable name into filename 添加命令名

3.运行程序，等停止退出后将生成的core文件，通过挂载u盘或者网络的方式拷贝到pc机Linux系统下，并和生成的可执行程序放在一个目录下。

ps：重启有可能会将上面的设置清除，最好运行前查看一番。

三、pc机Linux下分析core文件

1.先确定自己用的嵌入式处理器架构是ARM或者MIPS，选择相应的调试工具，下面以MIPS为例。mips-linux-gdb [exec file] [core file]

2.进入gdb以后需要运行info sharedlibrary来查看是否已经将需要的库导入，否则有可能查找位置时显示的是“？？”。

3.导入所需要的库，通过set solib-absolute-prefix 或者set solib-search-path 设置符号文件的位置。solib-absolute-prefix设置的是被搜索文件路径的前缀，solib-search-path设置的是被搜索文件的路径，solib-search-path可以有多个路径，中间按用:隔开， solib-absolute-prefix的值只能有一个。但一般常用solib-search-path 。

首先通过find或者其他方法找到所需要的库，“（gdb）solib-search-path 库路径：库路径”

 

4.最后通过bt命令查找到位置，基本就能确定程序死在哪个文件哪个函数了。可以通过“（gdb）l *地址”（如：（gdb）l *0x76b693dc）查看那个位置的函数，不过还是建议用source insight查看方便。

5.最后补充一个查看库文件结构的命令

 

Linux下动态库查看方法：nm -D lib.so

Linux下静态库查看方法：ar -t lib.a