SIGTRAP despite no set breakpoints; hidden hardware breakpoint?
I am debugging this piece of software for an STM32 embedded system. In one of the functions my programs keeps hitting some sort of breakpoint:
SIGTRAP, Trace/breakpoint trap
However, in GDB, when I do info breakpoints I get No breakpoints or watchpoints. The breakpoint actually corresponds to a breakpoint I had set quite some time ago, in another version of the executable. When I set that breakpoint, GDB told me automatically using a hardware breakpoint on read-only memory (or a similar message).
I think the hardware breakpoint remains on my chip, despite having loaded a new version of the software. If there is indeed a spurious breakpoint, how can I locate and remove it?
Answer
Ok. Long answer: Hardware breakpoints are usually set by writing to some special CPU registers. This is done by gdb. If gdb dies, it can left those installed in CPU. I guess your implementation (of gdb) does not either clear or examine those, when it connects to your target. To locate them, you would need to list the contents of hardware breakpoints registers on your CPU (don't know how to do this on STM32). Workaround would be (informed guess) be this: set few HW breakpoints (typically there are only a few, seldom more than 8) using gdb, then remove all of them. This should overwrite and then clean those hw registers. Once you do set those breakpoints (before removing them), do "continue" (just in case, as gdb sets breakpoints only at that time).