gdb - 找到在 cortex-m4 上发生中断的位置

标签 gdb arm cortex-m

我试图找到在我的代码中发生特定中断的位置。在这种情况下,它位于 stm32f4 微 Controller 上,中断是 SysTick_Handler。

我想要的基本上是找出系统中断发生的位置。我正在使用 arm-none-eabi-gdb 来尝试查找回溯,但我从那里得到的唯一信息是:

(gdb) bt
#0  SysTick_Handler () at modules/profiling.c:66
#1  <signal handler called>
#2  0x55555554 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?)

我怎样才能获得有关程序在中断触发之前所在位置的一些信息?

查看 arm 文档 here ,看来我应该能够读取堆栈指针,并从那里获取 PC。但这正是 GDB 中的展开器所做的,不是吗?

最佳答案

您在问题结束时走在了正确的轨道上。 ARM Cortex-M内核有两个堆栈指针,主堆栈指针(MSP,用于中断)和进程堆栈指针(PSP,用于任务)。

当有优先级中断进来时,当前寄存器值(对于大多数寄存器)被压入当前堆栈(PSP如果中断后台应用程序,或MSP如果中断一个较低优先级的中断),然后堆栈切换到 MSP(如果还没有)。

当您第一次进入中断时,链接寄存器(LR,返回地址)的值主要是 F 而不是实际的返回地址。这个值告诉核心在分支到时如何退出。通常,如果后台任务被中断,您将看到一个值 0xFFFFFFFD,如果一个较低优先级的中断被中断,您将看到一个值 0xFFFFFFF1。如果您使用浮点单元,这些值将不同。不过,这个值的神奇之处在于第 2 位 (0x4) 告诉您堆栈帧是在 PSP 上还是在 MSP 上。

一旦您确定了您的帧位于哪个堆栈上,您就可以通过查看适当的堆栈指针减去 24(6 个 32 位位置)来找到您正在执行的地址。请参阅链接中的图 2.3。这会将您指向您被打断的 PC。

关于gdb - 找到在 cortex-m4 上发生中断的位置,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38724658/

相关文章:

rust - 如何在 Rust 中更改 cortex-m4 处理器的异常优先级?

c++ - gcc 未声明的标识符 "_asm"

如果独立运行,gdb 下 Linux 上的 C 代码运行会有所不同吗?

c - 是否有适用于 *.elf 和 *.axf 的代码大小分析工具?

arm - 如何在使用 DS-5 时将文件读入目标内存

linux - uclinux编译错误

c - 中断服务例程不会跳回到 ARM Cortex M0 上的中断处理程序

python - 获取gdb的python接口(interface)中的所有全局变量/局部变量

python - gdb 内的 ipython shell

arm - 如果在启用 GDB 之前连接了 GDB,则不会触发 SysTick 中断