【发布时间】：2016-11-09 10:23:16
【问题描述】：
我目前正在开发板上的嵌入式 CPU (ARM cortex-M0)。我遇到了崩溃（HardFault），因此，我正在尝试调试它们。
目前我可以获得内存转储（我通过 printf 控制台以十六进制发送所有内容，这是我唯一访问内存的权限）。
我的想法是将该转储作为 coredump 加载到 gdb，从而能够调试程序。 如何从原始内存转储创建一个“真正的”核心转储文件，以便我可以直接将其提供给 gdb？
我还尝试在 gdb 模拟器中运行我的程序，以在我的原始内存中使用 restore 命令，但我不明白如何运行它。你有什么想法吗？
这里的主要问题其实是：如何根据程序elf和原始内存内容创建一个与gdb兼容的coredump文件？
【问题讨论】：
-
不能使用片上调试器有什么原因吗？
-
我怀疑内存转储是否足够；登记状态也是必要的。从 1999 年开始，sourceware.org/ml/gdb/1999-q2/msg00065.html 有一个关于此的主题。当您遇到硬故障时，您要求
printf在许多情况下仍然可以工作——尤其是在它被缓冲和中断驱动的情况下。在这种情况下，硬件调试器会更有效。 -
@Lundin cortex M0 调试器非常昂贵，而且板上没有。 Clifford：是的，我也有寄存器，而 printfs 实际上并不是 printfs，只是对硬件 FIFO 的写入。
-
此类项目的自定义做法是拥有硬件的调试版本。或者至少这就是我在处理涉及安全锁以防止逆向工程的项目时所做的。即使像评估板 + ICD + misc 手动焊接垃圾这样简单的东西也比通过 printf 调试要好。特别是因为 stdio.h 没有在生产代码中使用。
-
首先在硬故障处理程序中使用十六进制打印函数（反正你已经死了，不用担心在处理程序中你能做什么和不能做什么）转储堆栈并找出什么指令（地址) 导致错误，使用反汇编程序从该代码空间向后工作，使用该代码空间中的十六进制 printf 打印数据/地址值，以确认它们是您认为的导致相关指令的内容。
标签： debugging gdb embedded coredump