[
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
>