Support explicit hardware breakpoints (option to send "hbreak" instead of "break" to GDB)

[recursivenomad]

My hardware has 4 hardware breakpoints, so I pass set remote hardware-breakpoint-limit 4 to GDB during launch via my launch.json. However, if I set more than 4 breakpoints, GDB does not guard me from setting too many breakpoints as expected; instead it reports an error from the remote target that it "Cannot insert hardware breakpoint 5", and that "A serious error occurred with gdb, unable to continue or interrupt".

If I instead explicitly set 4 hardware breakpoints by manually passing hbreak to GDB, then attempting to set a 5th hardware breakpoint this way, GDB prevents me from setting this breakpoint and gracefully reports "Hardware breakpoints used exceeds limit", with no fatal errors.

When setting breakpoints in the UI, I can confirm that once they are sent from GDB to the gdbserver; seen with set debug remote 1, GDB is appropriately passing Z1 commands to automatically assign hardware breakpoints. But oddly enough, these automatic hardware breakpoints don't appear to count towards the hardware-breakpoint-limit. Upon querying info break, all breakpoints are listed as breakpoint, not hw breakpoint. This is contrary to what info break reports when manually passing hbreak to GDB.

The ideal solution for my use-case would be to allow users to specify how Cortex-Debug communicates breakpoints to GDB (specifically so I can set it to send hbreak instead of break).

This is already a feature in Microsoft's cpptools extension, however I would prefer not to rely on cpptools as it is largely closed-source, and I am attempting to maintain a fully FOSS development environment. I also do not know if that feature of the cpptools extension is even compatible with Cortex-Debug.

The following alternative solutions are not ideal workarounds for my use-case:

• Microsoft's cpptools extension (closed-source)
• Manually submitting hbreak to GDB (cumbersome, doesn't update UI)
• Intentionally avoiding setting more than 4 breakpoints (cumbersome, risks errors, unintuitive to new users)

For context, I am using Cortex-Debug with arm-none-eabi-gdb through OpenOCD to a Raspberry Pi Pico, communicating through a Picoprobe (an additional Pico running as a CMSIS-DAP debugger).

Thank you for developing and maintaining these extensions :)

EDIT - This issue is related to:

• How to insert hardware breakpoints？ #555

(After reading through #555, I'd like to emphasize that this feature request is simply asking to expose the commands Cortex-Debug is passing to GDB when calling breakpoints. I see no reason to change any default behaviour or VSCode UI, and I would be comfortable accepting that I only have 4 breakpoints as a result of this solution (I don't think I can get software breakpoints working anyway). All I suggest is exposing the breakpoint calls as a tool, such as an override through launch.json, for users who encounter issues like myself and those who commented in #555)

[litui]

I'd like to bump this request as well. In my particular case, debugging firmware running in RAM on a Cortex-A target, using a Black Magic Probe, BMP sends the correct memory map to gdb which includes RAM areas and this causes 'break' to select software breakpoints by default. The catch, however, is that software breakpoints have not yet been implemented for Cortex-A targets on BMP (work-in-progress).

This leads to breakpoints not being set at all when "break" is called. I've temporarily worked around the issue in a BMP fork by forcing Cortex-A software breakwatch calls to use hardware instead, but I'm not sure this is the right direction for a long-term fix.

It would simply be nice to be able to set the break command to be used by cortex-debug somewhere in the launch file.

[recursivenomad]

Chiming in a year later that I can all-but confirm this is caused by a bug in GDB itself. You can follow that bug report here.

In the meantime, an option to explicitly send hbreak instead of break to GDB would be a helpful workaround to prevent fatal errors, as I expect it will be a year or two before the bug is addressed, and then longer before a fix is shipped into the Arm GNU Toolchain releases.

Although I'm not familiar with VSCode extension development, I'm happy to help with a PR if given some initial direction.