[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-dd-dev] FW: hardware breakpoints
|
Hi Chris,
Look up the extension point org.eclipse.ui.actionSets. To see where
these are used in the UI, open the Window->Customize Perspective...
dialog, and look at the Commands tab. What is listed here are all the
registered action sets.
Following this pattern, it is probably an overkill to create a separate
action set just for setting hardware breakpoints. But if other related
functionality may be grouped along with hardware BPs, then this might
make a lot of sense.
-Pawel
Freehill Christopher-RAT063 wrote:
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
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
