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
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 :)
(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)
The text was updated successfully, but these errors were encountered:
recursivenomad
changed the title
Support explicit hardware breakpoints (send "hbreak" instead of "break" to GDB)
Support explicit hardware breakpoints (option to send "hbreak" instead of "break" to GDB)
Feb 7, 2024
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 passingZ1
commands to automatically assign hardware breakpoints. But oddly enough, these automatic hardware breakpoints don't appear to count towards the hardware-breakpoint-limit. Upon queryinginfo break
, all breakpoints are listed asbreakpoint
, nothw breakpoint
. This is contrary to whatinfo break
reports when manually passinghbreak
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 ofbreak
).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:
hbreak
to GDB (cumbersome, doesn't update UI)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)
The text was updated successfully, but these errors were encountered: