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

【问题标题】：How can I debug a bootloader and application in the same GDB session on Cortex-M devices?如何在 Cortex-M 设备上的同一 GDB 会话中调试引导加载程序和应用程序？
【发布时间】：2019-12-10 09:00:06
【问题描述】：

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

我附加了一个探针，运行 gdbserver，使用引导加载程序二进制文件启动 gdb。如果我运行file application.elf，那么我会丢失引导加载程序的符号。

我如何通过一次运行一条指令来观察切换，以及应用程序在跳转后立即执行的操作？

通过逐步跟踪 PC 并使用 addr2line 解码每个步骤，可以使用 SWD 指挥官，但我希望有更合适的方法。

【问题讨论】：

通常，实际的切换足够简洁，可以使用一侧的符号和旁边的窗口中的另一侧的一般意义/objdump 列表进行调试。另请注意，在许多此类设备上，在启动加载程序后进入应用程序的推荐方法是设置一个标志，重置处理器，在启动时很早就注意到标志并跳转到进行任何芯片配置之前的主应用程序。
除非问题出在bootloader，一般在主固件的入口点设置断点就可以了，如果问题出在bootloader，可以用其符号调试，手动查看主固件的入口点从其向量表中读取并分支到。往往真正需要复杂调试的是试图避免 CPU 复位的外围状态遗留问题，这就是为什么芯片制造商通常建议进行复位。
谢谢@ChrisStratton，非常有见地的方法，我会在开发产品时考虑到这一点。

标签： gdb embedded remote-debugging bootloader cortex-m

【解决方案1】：

您可以使用以下方式加载符号：

gdb add-symbol-file

【讨论】：

这在实践中可能存在问题，因为独立编译的引导加载程序和主固件项目之间可能存在传统符号名称的重复，其中一些源自编译器库以及用户代码和供应商中的符号名称批量重命名可能更容易达到的 hals。但是您可能会获得足够的独特性来解决问题。或者也许有人可以弄清楚如何重新处理一个以所有符号为前缀的精灵 - 硬件当然只关心唯一地址。
因为它只涉及一个引导加载程序，所以可以只卸载以前的符号，并在跳转完成后添加新符号。只需在两者之间的跳转处放置一个断点，然后手动切换即可。
当然，但是将一组完整的符号换成另一组是提问者已经知道如何使用 file 命令的操作。总的来说，添加一个额外的符号文件似乎是一个有用的技巧。