Chuong, Patrick wrote:
Hi Pawel,
See my
comments below yours.
Regards,
Patrick
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.
We'll do our best to support you.
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.
I hope that action sets are sufficient for most debuggers (they should
be for JDT and CDT at least), but if you need to use the active debug
context you can do that also. The only thing I would be careful about
is using the workbench part's selection to control a toolbar action.
The command framework only uses the active part's selection in
evaluating enablement expressions, so if your view is not the active
part, the action won't be enabled correctly.
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.
I see, in this case you should be able to control property pages for
your breakpoints completely.
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?
What we did in our (Wind River's) debugger is to allow each debug
target to move the bp as needed, but only update the location of the BP
in editor to match the first target's move. After targets disconnect,
the BP goes back to its original location. The situation where the BP
is moved to different locations is very rare, but this logic ensures
that if this situation does come up, the breakpoint doesn't end up in
some kind of a cycle being moved back and forth.
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.
I agree, if a scoping mechanism could guarantee that a BP would apply
to only one target at a time then moving BPs wouldn't be an issue. Are
you worried though that such a scoping mechanism would be too
restrictive?
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.
I think I understand our disconnect. In our product we took the
approach that breakpoint status is reported for each target
separately. This certainly complicates the UI, but if the Breakpoints
view used flexible hierarchy we could certainly improve on that. With
the backward compatibility requirements for Platform, I think it will
be very difficult to add restrictions that limit existing behavior and
APIs.
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!
You're welcome :-)
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?
Yes I agree, we already have enough clutter to go around. Here again,
I think creating a standard place to put these breakpoint actions (as
in bug 227394), then using the command framework to manage those
actions is the best bet.
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
|