如何在Cortex-M设备上的同一GDB会话中调试引导加载程序和应用程序？

经典设置：有一个引导加载程序和应用程序，分别编译。如果一切正常，引导加载程序将跳转到应用程序上

我附加一个探测，运行gdbserver，用引导加载程序二进制文件启动gdb。如果运行

文件application.elf

，则会丢失引导加载程序的符号

我如何通过一次运行一条指令来观察切换，以及应用程序在跳转之后做了什么

---

对于社会福利署指挥官来说，可能可以通过逐步跟踪电脑并使用addr2line对每一步进行解码来实现，但我希望有一种更合适的方式。

您可以通过以下方式加载符号：

gdb add-symbol-file

---

这在实践中可能会有问题，因为独立编译的引导加载程序和主固件项目之间可能存在传统符号名称的重复，一些源于编译器库以及用户代码和供应商HAL中的符号名称，这可能更容易通过批重命名来实现。但你可能会有足够的独特性来解决问题。或者，你可以想出如何重新处理一个以所有符号为前缀的elf——硬件当然只关心唯一的地址。因为它只涉及一个引导加载程序，你可以卸载以前的符号，并在跳转完成后添加新的符号。只需在两者之间的跳转上放置一个括号点，然后手动切换。当然，但是将一整套符号替换为另一套符号是询问者已经知道如何使用file命令的。不过，添加一个额外的符号文件看起来确实是一个有用的技巧。通常，实际的切换足够简洁，可以在旁边的窗口中使用一侧的符号和另一侧的常规sense/objdump列表进行调试。还要注意的是，在许多这样的设备上，在引导加载程序使用了大量芯片资源之后进入应用程序的推荐方法是设置标志，重置处理器，在启动时尽早注意标志，并在进行任何芯片配置之前分支到主应用程序。除非引导加载程序中存在问题，通常，在主固件的入口点上设置断点会起作用，如果问题在引导加载程序中，则可以使用其符号进行调试，并手动查看主固件的入口点是否从其向量表中读取并分支到。真正需要复杂调试的是试图避免CPU重置的外围状态遗留问题，这就是为什么芯片制造商通常建议进行重置。谢谢@ChrisStratton，非常有洞察力的方法，我将在继续开发产品时考虑这一点。