关闭

嵌入式core dump调试方法

947人阅读 评论(0) 收藏 举报

 一、为什么使用coredump

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

二、嵌入式下coredump生成设置

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

imageimage

2.设置core dump文件的输出位置,一般默认是当前目录,可以通过“echo “1” > /proc/sys/kernel/core_user_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来查看是否已经将需要的库导入,否则有可能查找位置时显示的是“??”。

image image

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 库路径:库路径”

 image image

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

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

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

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

1
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:956次
    • 积分:20
    • 等级:
    • 排名:千里之外
    • 原创:1篇
    • 转载:0篇
    • 译文:0篇
    • 评论:0条
    文章存档
    阅读排行