search

Marus / cortex-debug

Visual Studio Code extension for enhancing debug capabilities for Cortex-M Microcontrollers
MIT License
985 stars 238 forks source link

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

Open recursivenomad opened 7 months ago

recursivenomad commented 7 months ago

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:

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:

(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 commented 1 week ago

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.