You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am debugging a Raspberry Pi Pico (RP2040, ARM Cortex-M0+) via a Picoprobe (a second Pico used as the debug probe), from GDB through OpenOCD. I have encountered this bug on Windows 10 with arm-none-eabi-gdb, and on Debian 12 with gdb-multiarch.
I send GDB set remote hardware-breakpoint-limit 4 at launch. If I manually request hbreak four times, the limit is successfully reached, and a fifth hbreak request gracefully returns "Hardware breakpoints used exceeds limit".
If I instead request break (noting that GDB reports "Note: automatically using hardware breakpoints for read-only addresses." at launch), I can see that GDB is successfully sending Z1 packets; however, these automatic hardware breakpoints do not appear to count towards the gracefully monitored hardware-breakpoint-limit. Listing these breakpoints with info break reports they are of Type "breakpoint" (not "hw breakpoint").
The result of this bug is that requesting more breakpoints than the hardware supports will result in a fatal error, requiring GDB to restart.
For my development environment, manually submitting hbreak is not a graceful workaround, as my debugging interface (VSCodium/VSCode) automatically submits break when creating breakpoints through the UI.
The text was updated successfully, but these errors were encountered:
I am not sure if this is a bug with GDB, or something to do with debugprobe not relaying the appropriate information back to GDB.
From the GDB issue:
The text was updated successfully, but these errors were encountered: