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)