Hi Pawel,
See my comments below yours.
Regards,
Patrick
From: platform-debug-dev-bounces@xxxxxxxxxxx
[mailto:platform-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Friday, June 26, 2009 5:55
PM
To: Eclipse Platform Debug
component developers list.
Subject: Re: [platform-debug-dev]
Breakpoint Enhancements
Hi Patrick,
My comments below,
Chuong, Patrick wrote:
Hi,
I have a call with Samantha and Natasha regarding
breakpoint support in platform debug. Below is the consolidated list of
requirements from the call and we are hoping some of these can be done for the
next eclipse release (3.6?).
Convert
breakpoint view to flexible hierarchy (238956) – See comment #7
Ability
to group breakpoint based on active debug context, column support, In-place
editing support
I hope this means upgrading the Breakpoints view to
use flexible heirarchy :-)
Yes this is what I mean. I can help in this
area. I am new to the flexible hierarchy from the platform, I probably will
need some guidance and help from you guys here.
Dynamically
contribute new breakpoint actions based on active debug context
Actions
can be contributed to editor, variable view, _expression_ view, disassembly view,
outline view, project view, memory view, and others
Have a
central place to create new breakpoint for views and editors (227394) – such as Java Exception, Java Class
Load Breakpoint, C++ Event Breakpoint, C++ Watchpoint, Line Breakpoint, etc..
I don't think we need to use the debug context to
control action visibility, using action sets achieves a somewhat more
consistent behavior. Please take a look at bug 246243.
There I converted the JDT actions to commands and I added the use of action
sets to control their visibility, but the bug is blocked waiting for an API
from the Workbench team.
I am not sure whether the action set is sufficient. For my use
case, depends on the current debug context and the workbench part’s
selection, the set of action will be different.
Dynamic
properties (attributes) page
There
need to be a way to contribute breakpoint properties dynamically based on the
active debug context. The properties page can be put in the details pane of the
Breakpoints view or in a Properties dialog.
Isn't this CDT-specific? And in CDT, we
currently already have property pages which are enabled depending on the debug
model. See bug
211533 and the org.eclipse.cdt.debug.BreakpointExtension extension point.
I am not using CDT breakpoint, I have my custom breakpoint
implementation that works side by side with CDT breakpoint.
Scoping
of breakpoints based on debug target
Scoping
of breakpoints based on debug target
If the
user has added a breakpoint on an invalid line, one target decides to move the
breakpoint to a new location. Other targets get affected as well because they
might not be able to move the breakpoint to the new location. We need a way to
properly scope breakpoint to a debug target.
Moving breakpoint line seems like a separate issue
from scoping. Yes scoping breakpoints to the correct target needs to be
improved. For moving the breakpoint to different location, it should be
enough to keep the original requested line in the marker and restore it once
the breakpoint is uninstalled.
I agreed with the scope is a separate issue than moving the
breakpoint. How can this be handled when there are multiple breakpoint listeners?
One listener might agree to move, while another listener might not agree to move?
Doesn’t this mean there needs to be a mechanism to have all listeners
agreed before moving the breakpoint?
I think this will be tied with scope. If the breakpoint is scoped
to a target, than there is no need to have all listener to agree before moving.
Additional
requirements from my self since our discussion over the phone
Breakpoint
hit / triggered indicator
Indicate
when a breakpoint is hit and triggered
Ability
to disable breakpoint modification, add, remove, and modify properties
Target
might not be able to handle breakpoint request while target is running
I can't imagine how this will be possible (the disable
part), given that breakpoints are shared. Why can't the target just
ignore changes after installing the breakpoint.
If the target ignore the changes, than you will have an inconsistence
between what is show in the view and the target. For example. If the target is
running and breakpoint can’t be remove from the target. User removes the
breakpoint from the view and the expectation will be not suspending the target
at the breakpoint location. But this is not true in this case.
I can see this can be done if we have a handshake mechanism –
where the view will ask each registered listener whether the action is enabled
or not.
Notes/Issues:
CDT now
provides a way to contribute breakpoint actions to the views and editors, these
actions are tied to plugin.xml file. Debugger that do not work with CDT need to
remove the actions to avoid duplication, which causes confusion to the user.
So, there needs to be a way to contribute breakpoint actions based on the
active debug context.
One
thing that is not clear is how to handle breakpoint action without a debug
context.
Will
the platform provide generic breakpoint action contribution to create an
offline breakpoint? The generic breakpoint can have a standard set of property
and debugger can translate the standard properties to the backend flexible
property when consuming the breakpoint.
When
debuggers are launch, which debugger will consume the offline breakpoint? What
policy?
Have you looked at bug 212316, it
is meant to deal exactly with this problem.
Yes, I am relying on this patch to create my own custom breakpoint
type. Thanks for the patch!
My note was referring to the watchpoint, exception, event
breakpoint, etc… contributed by different debugger. When I add a new
debugger to the picture, than additional watchpoint, exception, etc…
actions will be duplicated. Can this be cleanup based on the active debug
context?
I am hoping that the community can provide feedback
and help me to gather additional requirements and I’ll be able spend
times to help to extend the breakpoints support for the next eclipse release.
Me too :-)
-Pawel
Regards,
Patrick
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
