gdb调试程序coredump总结

gdb 作为程序调试的一种手段，其功能强大,１　可以给程序设置断点，调试程序状态　２　调试程序coredump,查找程序产生coredump的原因和位置．

gdb的使用方法有两种，一种是时时监测程序
gdb + 可执行程序（添加了-g编译选项）
第二种　当程序执行时产生coredump 文件
gdb + 可执行程序（添加了-g编译选项） + coredump 文件

gdb 调试基本环境搭建：

在执行gdb的时候，因为我们的程序在编译的时候会链接一些库，当我们使用某个函数出现问题的时候，追根溯源会找到相应的库。那么我们在调试程序的时候，就需要把对应的库的path告诉gdb
这个时候，我们需要使用两个命令：
set solib-search-path lib_path //我们应用程序所使用的库的位置
set sysroot sysroot_path //我们sysroot 所在的库的路径
这样，在追根溯源去找我们程序崩溃的位置，就会很轻松了

在你的嵌入式设备上面打开生成 core文件开关

ulimit -c unlimited //因为core文件比较大，多以要配置一下，否则不会生成core文件
同时我们也可以通过ulimit修改栈区的size大小.默认是8M,当程序比较大时,就容易出现段错误.可以将其设置为200M
也是在文件末尾添加:ulimit -s 204800 重启开发板即可.
这个记录在这里吧，比较重要的一个系统设置
echo /usr/core_log/core_%e_%t_%p > /proc/sys/kernel/core_pattern //通过这个命令来命名每次产生coredump的名字
通过以上两个命令的设置就可以正确的产生coredump了

%%单个%字符

%p所dump进程的进程ID

%u所dump进程的实际用户ID

%g所dump进程的实际组ID

%s导致本次core dump的信号

%t core dump的时间 (由1970年1月1日计起的秒数)

%h主机名

%e程序文件名

GDB 调试中遇到的问题

bt追踪栈信息，出现 ？？无函数名的情况

gdb 调试堆栈信息的时候，很容易遇到打印不出具体哪个函数哪一行信息的时候，这样的话一个偶现的问题你折腾一圈，却没有直接定位问题，很是费力不讨好啊。
我再啰嗦一句，随着你的成长，在遇到问题时我们一定要养成可以根据实际情况分析问题的能力，第二点遇到问题我们要能够正向思考，去找到root case。

gdb 出现这种问题，就是没有找到对应位置的符号，我们要在使用工具的时候看工具的提示：
warning: .dynamic section for “/home/jetpack/work/OKMX6UL-C2/fsl-linaro-toolchain/arm-fsl-linux-gnueabi/multi-libs/lib/libc.so.6” is not at the expected address (wrong library or version mismatch?)，
当看到这一行时，你就可以注意到是自己加载库的问题，和运行时的库不匹配。
请参考这个文章：
https://blog.csdn.net/lhl_blog/article/details/106542754
嵌入式Linux应用崩溃调试-难以追踪的栈信息