[dsdp-dd-dev] FW: hardware breakpoints

["Freehill Christopher-RAT063" <ChrisF@xxxxxxxxxxxxx>]

Hi,

We're looking at implementing hardware breakpoints (HW BPs) and would
like to get feedback to see what other ideas people have about how HW
BPs should be supported, and what, if anything, could be shared with the
community. We've implemented some of this, but would like feedback
before going much further.

Our current thinking is to add a sibling menu item to "Toggle
Breakpoint" called "Toggle Hardware Breakpoint". "Toggle Breakpoint"
would mean the user would want to set an auto breakpoint. By auto
breakpoint, I mean, if possible, set a software breakpoint (SW BP), and
if that fails, set a HW BP. The idea being that a user would normally
want to use SW BPs, but sometimes (for example, in ROM) this isn't
possible.

Of course if the user explicitly wants a HW BP (regardless of whether a
SW BP can be set), he can use "Toggle Hardware Breakpoint".

For explicitly set HW BPs, and BPs that are HW BPs as a result of
setting an auto breakpoint, a decorator would be added to the blue dot
icon that indicates that the breakpoint is a hardware breakpoint. 

To clear a HW BP, a user could either click on "Toggle Breakpoint" or
"Toggle Hardware Breakpoint". To remove a non-HW BP, the user would
either double click the BP, or click on "Toggle Breakpoint"; "Toggle
Hardware Breakpoint" would be disabled. The reasoning being that a HW BP
is a BP, but the reverse isn't true; i.e., if an auto BP resulted in
successfully setting a SW BP, it would not make sense to be able to
"Toggle Hardware Breakpoint" on that BP.

Persistence of breakpoints would be handled as follows:
-BPs explicitly set as HW BPs would remain HW BPs on subsequent debugger
sessions

-BPs that are HW as a result of setting an auto breakpoint would remain
auto in subsequent debug sessions. For example, say in the first session
a user sets an auto BP, but software breakpoints are not available at
the indicated location, so a HW BP gets set. Then, the user kills the
session and changes the HW so that a SW BP can now be set at the
location in question. Since the user originally set an auto BP, a SW BP
should be set and not a HW BP.

To facilitate all of this, 2 new boolean attributes would be added to
breakpoints
	

AUTO_BREAKPOINT (otherwise known as REGULAR breakpoints) is necessary to
ensure that auto BPs remain auto, and do not turn into HW BPs across
multiple debug sessions.

HARDWARE_BREAKPOINT is necessary more within a single debug session to,
for example, indicate that the hardware decorator should be displayed,
or that we need to tell the debugger back end to set a HW BP and not a
SW BP.

3 of the four possible combinations of these two attributes are
possible. At least one of the 2 attributes must be true.

...that's pretty much it.

Please let me know any comments you have about whether you like or
dislike this approach to handling HW BPs, and if you see any potential
implementation problems, or have comments about what should/could be
shared.

Thanks,
Chris Freehill
Freescale