嵌入式imx6板GDB分析core dump：如何获取更多回溯信息？

我来帮你一步步解决这个问题——在嵌入式Yocto环境下用GDB分析core dump却拿不到有效信息的情况太常见了，主要是符号缺失或者GDB配置不到位，咱们从根源开始排查：

回溯信息无价值，90%的概率是你的程序没有带调试符号，或者GDB没法正确识别符号：

• 编译时必须加调试符号：编译C++程序时一定要加上-g3参数（比-g包含更多宏、类型信息），同时别用-O2及以上的优化级别——优化会打乱栈帧结构，直接让GDB没法解析调用栈。在Yocto的recipe里，你可以加这两行来确保编译出带符号的二进制：

  CFLAGS += "-g3 -O0"
  CXXFLAGS += "-g3 -O0"
  

• 确保GDB匹配目标架构：iMX6是ARM架构，你得用Yocto构建的原生ARM GDB，不能拿x86的GDB凑数。启动时的警告如果是架构不匹配、符号加载失败，大概率就是这个问题。
• 手动加载符号文件：如果程序是在主机交叉编译的，把带符号的原版二进制（不是设备上被strip过的精简版）传到设备上，然后在GDB里先执行file /path/to/your/debug-binary加载符号，再用core-file /path/to/core加载core dump。

符号搞定后，用这些GDB命令就能拿到有用的栈信息：

• bt full：别只用bt，这个命令会打印每个栈帧的完整细节，包括局部变量、参数值，比单纯的调用栈列表有用得多。
• up/down：在栈帧之间切换，up就是跳到**上层（调用当前函数的父函数）**栈帧，配合info locals查看上层函数的局部变量，info args查看传入的参数。
• frame <n>：直接切换到第n个栈帧（bt会列出每个栈帧的编号），然后用list命令查看这个栈帧对应的代码位置，就能知道上层函数是怎么调用当前函数的。
  如果还是看不到上层栈帧，可能是栈被破坏了（比如缓冲区溢出），这时候可以试试：
• info registers：查看寄存器状态，重点看sp（栈指针）和pc（程序计数器），手动推算栈帧的位置。
• x/100x $sp：打印栈指针附近的内存，找可能的返回地址，再用info symbol <地址>查看这个地址对应的函数。

• 确认core dump功能开启：先在设备上执行ulimit -c，如果输出是0，说明没开启core dump，执行ulimit -c unlimited临时开启，或者在/etc/security/limits.conf里配置永久生效。
• 优化GDB的输出格式：在GDB里执行set print pretty on，让C的结构体、类打印得更清晰；执行set print demangle on，确保C的重载函数名被正确解析（不会看到一堆乱码的mangled名字）。
• 结合日志与系统调用跟踪：把程序的打印输出和core dump时间对应起来，定位崩溃前的最后操作；还可以用strace -o strace.log ./your-program跟踪系统调用，看崩溃前最后执行的系统调用是什么，缩小排查范围。

内容的提问来源于stack exchange，提问作者adowdy