RE: [dsdp-dd-dev] FW: hardware breakpoints

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

Hi Martin,

Maybe HW BPs could be coupled with the expanded support you mention
using Action Sets Pawel talked about.

Hmmm...some of that expanded support could be useful for us as well.

chris

> -----Original Message-----
> From: dsdp-dd-dev-bounces@xxxxxxxxxxx 
> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of 
> Swiezawski, Martin
> Sent: Tuesday, June 13, 2006 8:25 AM
> To: Device Debugging developer discussions
> Subject: RE: [dsdp-dd-dev] FW: hardware breakpoints
> 
> 
> Hi Chris, 
> We have very similar functionality in our debugger as well. 
> In our case the backend debugger takes care of setting HW bps 
> if SW can not be set. We are also adding context menu's to 
> set HW breakpoints and unique markers to distinguish between 
> SW & HW breakpoints. 
> 
> We are also interested in expanded support for HW 
> breakpoints, where more configuration settings are exposed to 
> the user. E.g. support for range breakpoints, conditional HW 
> breakpoints and improved support for HW watchpoints. HW 
> watchpoints could have a number of different settings such as 
> data bus size, masks, data values, etc. Also, ability to set 
> actions other than halt, e.g. execute a script. 
> 
> Martin
> 
> 
> 
> 
> -----Original Message-----
> From: dsdp-dd-dev-bounces@xxxxxxxxxxx 
> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of 
> Freehill Christopher-RAT063
> Sent: Friday, June 09, 2006 2:18 PM
> To: dsdp-dd-dev@xxxxxxxxxxx
> Subject: [dsdp-dd-dev] FW: hardware breakpoints
> 
> 
> 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
> _______________________________________________
> dsdp-dd-dev mailing list
> dsdp-dd-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> _______________________________________________
> dsdp-dd-dev mailing list
> dsdp-dd-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
>