Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-dd-dev] FW: hardware breakpoints

Hi Pawel,

By "action set" do you mean something like a sibling to "Run As", etc.?
Sorry, I'm all that familiar (yet) with the terminology.

That's a good point--it would not be useful to many users. I was trying
minimize the inconvenience to those do use it, because I imagine some
users will use it frequently. It's a trade off. Could you please further
describe what you had in mind with the action set?

chris

> -----Original Message-----
> From: dsdp-dd-dev-bounces@xxxxxxxxxxx 
> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
> Sent: Monday, June 12, 2006 12:52 PM
> To: Device Debugging developer discussions
> Subject: Re: [dsdp-dd-dev] FW: hardware breakpoints
> 
> 
> Hi Christopher,
> We also have a set of actions and properties for dealing with 
> hardware 
> breakpoints, although we don't have an "auto" option which actually 
> sounds pretty useful.  My question is whether you think that "Toggle 
> Hardware Breakpoint" action should be put into a new action set for 
> hardware breakpoints, so that most users who do not have this 
> capability 
> are not confused by the new option?
> 
> Cheers
> Pawel
> 
> Freehill Christopher-RAT063 wrote:
> > 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
> 


Back to the top