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
o
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 :-)
-
Dynamically
contribute new
breakpoint actions based on active debug context
o
Actions
can be contributed to
editor, variable view, _expression_ view, disassembly view, outline view,
project
view, memory view, and others
o
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.
-
Dynamic
properties (attributes) page
o
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.
-
Scoping of
breakpoints based on
debug target
o
Scoping of
breakpoints based on
debug target
o
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.
Additional
requirements from my self since
our discussion over the phone
-
Breakpoint
hit / triggered indicator
o
Indicate
when a breakpoint is hit
and triggered
-
Ability to
disable breakpoint
modification, add, remove, and modify properties
o
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.
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.
o
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.
o
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.
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
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
|
