SIGTRAP despite no set breakpoints; hidden hardware breakpoint?

Question

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 1

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).

Answer 2

The following helped me:

# Ones I hit the SIGTRAP:
(gdb) f 0  # Show the current stack frame of the current thread.
#0  0x4003ed70 in pthread_create@@GLIBC_2.4 () from /opt/CodeSourcery/arm-2011.09/arm-none-linux-gnueabi/libc/lib/libpthread.so.0

# The fragment of interest is the current address: 0x4003ed70.
# Set the hardware assisted breakpoint at the current address:
(gdb) hbreak *0x4003ed70

# Continue execution (without hitting SIGTRAP):
(gdb) c
# Continuing.

Answer 3

SIGTRAP should be a breakpoint instruction that's being run.

Debug this by inspecting your instruction pointer, it's most likely pointed at an address that contains the BKPT instruction (you'll have to look up what the actual code is).

From there you'll have to work backwards based on the stack and instruction pointer and see if you're where you expect to be. There could be a number of things causing this, from GDB inserting a breakpoint instruction that it failed to clear, to memory corruption.

Answer 4

If adding and removing hardware breakpoints does not help, check the interrupt vector.

On Cortex-M microcontrollers all handler entries should have an odd address ( ARM Cortex-M FAQ ). If they don't, then a UsageFault of type INVSTATE is triggered and the MCU is halted. GDB interprets this as a SIGABRT.

If one of the entries has an even address, then check if the handler function has the .thumb_func and .type directives ( NXP Avoid hardfault , HardFault and .thumb_func ).

Example for a HardFault_Handler:

.thumb_func
.type HardFault_Handler, %function
HardFault_Handler:
  TST LR, #4
  ITE EQ
  MRSEQ R0, MSP
  MRSNE R0, PSP
  B hard_fault_handler_c

Answer 5

The code you are running may contain

int $0x03 ; talking about x86, don't know STM32 mnemo

which invokes a SIGTRAP.