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
