关于处理程序异常后的core dump后的stack解析问题
目前:
1. 嵌入式MIPS系统,没有JTAG
2. 由于很多数据是硬件运算的,无法在PC的模拟版本调试
3. 目前已经可以dump出出错时的SPR和GPR,以及堆栈信息,包括所有线程的堆栈
4. 程序使用一些库,使用了-O2优化,一些函数调用的fp可能没有
问题是:如何在这样的情况下,解析出堆栈的调用信息?这样我们就可以知道到底是在何处走的哪条路径以及给了什么样的参数造成程序崩溃的。
目前我还是不清楚怎么样才能知道每个call frame的大小,如果不知道这个大小,看样子很难得到解析栈的调用关系
谁能给些思路。。
相关推荐
Accelerated_Linux_Core_Dump_Analysis
该书主要介绍Linux系统中核心转储(core dump)的模式和实践方法,适用于具有一定软件开发和基础故障排查经验的读者,同时也假定读者熟悉十六进制记数法和至少一种编程语言的源代码阅读。
C++程序崩溃调试实战:从Core Dump分析到问题定位
程序崩溃是软件开发中常见的挑战,其本质是进程因未处理的异常或非法操作而意外终止。理解其原理,关键在于掌握系统在崩溃瞬间生成的完整内存快照——Core Dump(Linux)或Dump文件(Windows),它记录了线程栈、寄存器等关键现场信息。这项技术的核心价值在于,为事后调试提供了不可替代的“黑匣子”,是构建高稳定性桌面应用、后台服务和嵌入式系统的基石。通过配置系统生成完整的转储文件,并借助GDB、WinDbg等调试器配合精确的符号文件进行分析,开发者可以高效地勘查调用栈、检查内存状态,从而定位访问违例、
Accelerated Linux Core Dump Analysis Training Course
课程内容专注于如何通过核心转储(core dump)分析来找出Linux应用程序中的问题,并帮助开发者进行故障排除。
玩了一次linux的crash工具。真TMD牛逼.docx
一、使用 Crash 工具对 Linux 系统进行分析首先,我们需要将 Dump 文件合并成一个文件,使用以下命令:`cat sysdump.core.* dump.bin`然后,我们需要下载编译版本的符号表
段错误(linux)
**查看core dump文件**:当程序崩溃时,Linux系统会自动生成一个名为core dump的文件,该文件记录了程序崩溃时的内存快照,有助于定位问题。 - 查看命令:`gdb .


工具平台和程序库
