[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-dd-dev] FW: hardware breakpoints
|
My description may not have been clear. We are pretty much doing the
same thing. i.e. standard Toggle Breakpoint will also have "Auto"
behaviour. Our backend debugger automatically sets HW bp if SW can not
be set. One item that I am not sure how we handle yet is that ideally
that Auto HW breakpoint would be actually shown as a HW bp.
Martin
-----Original Message-----
From: dsdp-dd-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Tuesday, June 13, 2006 12:05 PM
To: Device Debugging developer discussions; Device Debugging developer
discussions
Subject: RE: [dsdp-dd-dev] FW: hardware breakpoints
Ah, OK. So I misinterpreted your description; I thought you had a
dedicated menu item for "Set S/W breakpoint", not that you reused
"Toggle Breakpoint".
So, this is where things get a little messy. For Freescale, we plan
on using "Toggle Breakpoint" to represent setting/clearing an "auto"
breakpoint, as per Chris' description of what "auto" means. We don't
foresee the the user wanting to request a software breakpoint
explicitly--i.e., "set a SW breakpoint, and ONLY a SW one or fail",
so our plans don't include a "Set SW breakpoint" action either
implicitly or explicitly.
Since we are talking about coming up with a common approach, I wonder
if you guys really see the need for that sort of thing? If not, then
you could adopt our approach of just having the notion of Auto and
HW. breakpoints. If not, then maybe we can adjust our plans and come
up with a design that recognizes all three types: SW, HW and Auto.
John
At 10:42 AM 6/13/2006, Swiezawski, Martin wrote:
>John,
>We have both options visible. As Patrick mentioned we allow multiple
>breakpoints on the same line. If HW breakpoint is set, then a HW icon
>appears. If user then selects toggle breakpoint, then SW bp would be
set
>as well. This is not the cleanest solution when dealing with just HW &
>SW breakpoints that halt the target, however, multiple breakpoints on
>the same line can come in handy when you want to support different
>"actions". E.g. run a script and refresh a window.
>
>We use CDT as well.
>
>Martin
>
>
>-----Original Message-----
>From: dsdp-dd-dev-bounces@xxxxxxxxxxx
>[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
>Sent: Tuesday, June 13, 2006 11:08 AM
>To: Device Debugging developer discussions; Device Debugging developer
>discussions
>Subject: RE: [dsdp-dd-dev] FW: hardware breakpoints
>
>Martin,,
>
>Thanks for the added detail. So, are you able to avoid/remove the
>platform's "Toggle Breakpoint" menu item, or do you just tell users
>to ignore it? I'm guessing you're able to avoid it since you guys
>have your own editor and plug in at the platform level. We're
>CDT-based, so that will be trickier for us.
>
>John
>
>At 09:22 AM 6/13/2006, Chuong, Patrick wrote:
> >John,
> >
> >I'll take a stab and answer what Martin has point out about the TI
> >debugger's breakpoint manager.
> >
> >At any time, you get two options to toggle s/w breakpoint and h/w
> >breakpoint at a line. If there is a s/w breakpoint set at a line,
than
> >you get the additional sub-menu to "remove", "disable", and "edit".
If
>a
> >breakpoint is already disabled, than the disable option is replaced
>with
> >"enable". The edit option will open up the property window to allow
the
> >user to fine tune the breakpoint. The kind of options is listed from
> >Martin's email.
> >
> >Additionally, you can set as many breakpoints on a line as you want.
>Due
> >to the limited context menu real-estate, this has to be done through
>the
> >Breakpoint Manager UI, but there will be one icon in the left margin
to
> >represent each breakpoint.
> >
> >This also applies to the disassembly window as well. You can set
varies
> >of breakpoint in the disassembly window and source window (editor) on
> >the same line.
> >
> >Regards,
> >Patrick
> >
> >-----Original Message-----
> >From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> >[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
> >Sent: Tuesday, June 13, 2006 9:37 AM
> >To: Device Debugging developer discussions; Device Debugging
developer
> >discussions
> >Subject: RE: [dsdp-dd-dev] FW: hardware breakpoints
> >
> >Martin,
> >
> >I'm curious how you were planning to deal with the menu. The existing
> >"Toggle Breakpoint" menu item poses some significant design
> >challenges. Ideally, when there's no breakpoint at a line, the user
> >would have
> >
> > Set Breakpoint
> > Set Hardware Breakpoint
> >
> >and on a line where there was a breakpoint, those two would be
replaced
> >with
> >
> > Clear Breakpoint
> >
> >But I don't think this is possible. What approach where you thinking
of
> >taking?
> >
> >John
> >
> >
> >At 08:24 AM 6/13/2006, Swiezawski, Martin wrote:
> > >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
> >
> >_______________________________________________
> >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
>_______________________________________________
>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
