gdb – 从Flash启动时断点不起作用

发布时间：2020-12-15 07:23:38 所属栏目：百科来源：网络整理

导读：在过去,我一直在调试加载到Cortex M3(STM32F2)内部SRAM中的可执行文件,没有任何问题.我最近一直在将我的可执行文件加载到Flash(因为大小问题). 从那时起,使用GDB进行调试一直没有奏效.据我所知,当可执行文件在Flash中时,只能使用硬件断点(而不是软件断点),而

在过去,我一直在调试加载到Cortex M3(STM32F2)内部SRAM中的可执行文件,没有任何问题.我最近一直在将我的可执行文件加载到Flash(因为大小问题).

从那时起,使用GDB进行调试一直没有奏效.据我所知,当可执行文件在Flash中时,只能使用硬件断点(而不是软件断点),而且我有六个硬件断点.但是,当只设置一个硬件断点时,GDB会产生一条错误消息：

(gdb) break main
Breakpoint 1 at 0x800019a: file src/main.c,line 88.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) Warning:
Cannot insert hardware breakpoint 1.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

怎么可能出错？我的硬件断点是在后台拍摄的吗？

注意：我使用OpenOCD通过JTAG加载可执行文件.

解决方法

因此,基本上有两种方法(加上一种非常糟糕的方式)可以在任何给定的调试器/平台组合上实现断点：

>使用某些硬件功能(“硬件断点”)使处理器在到达特定地址时陷阱.这通常仅限于几个断点,如果它可用的话.
>对于正在设置的每个断点,将断点处的指令替换为某种类型的“陷阱”指令(即,将进入调试器的指令).当其中一个断点被击中时,重新交换原始指令并单步执行一次以使其运行.
>单步完成整个计划.这一点并不重要,因为它的速度非常慢.

听起来好像你的调试器只使用方法#2(“软件断点”).使用这种方法的问题是它需要程序可写 – 闪存一次不能写入一条指令,因此这种技术不起作用.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!