Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GDB automatic breakpoints do not count as hardware breakpoints #144

Open
recursivenomad opened this issue Jun 15, 2024 · 0 comments
Open

Comments

@recursivenomad
Copy link

recursivenomad commented Jun 15, 2024

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:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant