[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-dd-dev] FW: hardware breakpoints
|
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
