Hi Darin,
I named it a wish list because I started out with: "Wouldn't it be
great if we could..." So this is really just a brainstorming list
without regard for effort or scope. It was mostly intended as a way
for to start a discussion about the planning process for the next
release. Speaking more directly though, do you have plans for having
any phone or face-to-face meetings for such planning? I remember
you've mentioned in the past that such a meeting could be very
productive for hashing out some of the finer details of UI and
workflow. If so, the best timing for us would probably be rather soon,
in mid August, as other Eclipse meetings (CDT, ESE, etc) quickly
approach in months ahead.
Thanks,
Pawel
Darin Wright wrote:
> Hi All,
> Doug Gaff asked me to follow up after the recent Platform Debug
team
> committer diversity discussion with a general list of tasks that
> Wind River would like to work on in the Platform. Here is the
list
> we came up with.
>
Thanks, Pawel. If this is a "list of tasks
that
Wind River would like to work on", then perhaps it should be a "work
list" rather than a "wish list". Than again, from a platform
point of view, it is also our "wish" that these are things that
Wind River will work on :-)
I've added my comments below.
> Embedded/Remote debugging
> Better Integration with Target Manager
> This is probably more of a TM task but
it's also
part of an over-all
> debugger experience:
> Ability to drive debugger views from
within TM
> Create a GDB debugger sub-system to
configure
GDB and to manage GDB sessions.
> Standard launch dialog pages for
configuring
TM.
> Configure new targets and sub-systems
> Download using ftp
> Run shell scripts
> etc.
These do sound like target management issues.
Other
members in the diversity discussion also expressed interest in generic
support for deployment to targets before debugging/running an
application.
Would the ftp part of this be even more general, or should it be part
of
debug?
> Better breakpoint management in a
multi-core
environment
> Create a first-class object representing
breakpoint
"scope". I.e.
> which targets/threads should a breakpoint should be installed with.
> Create a linking between projects,
launches and
breakpoint scopes.
This is also interesing for Java, as users
often get
confused when they have duplicate source files in the workspace, or
files
with the same name in the workspace. Setting a Java breakpoint results
in any matching qualified type name to install the breakpoint (no
matter
which project the type originated from). It would be nice to avoid
scoping
breakpoints by specific model objects (IDebugTarget, etc)., since we no
longer require a model to implement the standard interfaces.
It would also be nice to open the breakpoints
view
to the flexible hierarchy scheme... but there are issues since we have
added grouping mechanisms.
> Power User features
> *Scripting/Macros
> A feature for executing a list of
"actions"
is already implemented
> in CDT. It could be made more generic and moved to platform.
> Scripts should be capable of:
> Debugger operations
> Run control
> Breakpoint control
> Reading/Writing memory
> UI operations
> Showing data in views. This could be
problematic
with existing
> views architecture, perhaps "quick" views could be used
instead.
> Positioning editor.
> Users should be able to "record" scripts
based on a series of
> actions in the debugger.
> I think the new command framework could
provide
some of the
> infrastructure for this feature.
The new command framework may help for
generic record/replay
of commands. However, the debugger adds complexity, since it operates
asynchronously.
The replay would have wait for commands to finish asynchronously (and I
don't think that's built into the command framework).
What the is the motivation for "positioning
the
editor"? In terms of stepping/displaying source - this happens as
a reaction to debugging (and would still work as a side effect of
scripting).
> *Common API for creating breakpoints
> Currently, there is no single non-UI API
for
creating breakpoints.
> This is a blocking feature for any kind of meaningful scripting
> support. We should investigate to see if it makes sense to
provide
> such an API.
This is tricky, as breakpoint creation is
model specific.
However, we do support import/export of breakpoints (not API yet), and
we might be able to use this feature to support breakpoint creation via
a script. Basically, we persist breakpoint marker attribtues, and
recreate
the markers/breakpoints (as is done in a workspace shutdown/restart).
> Integration with static symbols
> Currently static symbol databases and
debugger
symbol data retrieved
> from object files don't mix very well. We should investigate
to see
> if it would be possible to integrate the UI of the two a little
bit
> better. But currently, the only use cases I can think of are
> Creating method breakpoints from the
outline
views and from the
> editor by right-clicking on the method declaration.
> Showing method breakpoints in the editor
gutter
based on static
> symbol information.
> Provide access to static (in addition to
debugger)
symbol
> information when creating a symbol breakpoint or choosing the
object
> entry point.
I'm not sure how symbol stuff fits into the
platform.
> *"Quick" views for debugger data
> Quick outline (Ctrol-O) and type
hierarchy (Ctrl-T)
views accessible
> from the editor, as well as javadoc toolstips and method
completion
> have made the experience of writing java code much more enjoyable.
> Debugging seems ripe for similar kind of workflow improvement.
Some
> ideas for better debugger workflow are:
> A smart watch view that only shows data
relevant
to the selected
> context. It should also be capable of displaying more than just
> variables and registers, such as threads, breakpoint status,
memory
> blocks, etc.
> Quick views for Variables, Registers,
Watch,
and Memory. Or better
> yet, a quick view version of the smart watch dialog mentioned
above.
> Interactive popups in the editor for
variable
values. To allow the
> user to drill-down through the data.
> Oddly enough, these ideas may not even
require
any changes in
> platform, but could be implemented as extensions.
I think these could be created as extensions.
Note
that the Java debugger does have a popup for inspecting data structures
in the editor or else where (select a variable and use the "Inspect"
action). This popup-dialog is available in the debug platform as API -
see InspectPopupDialog and DebugPopup.
> *Truly integrated Java/C debugging
> By truly integrated, I mean I imagine
stepping
into a JNI call in
> java and seamlessly transitioning to C debugging. By seamlessly,
I
> mean: the Debug view should have a single debug target, which is
> showing a stack trace with both java and C stack frames. I think
> the only way we'll achieve this kind of integration is by writing
UI
> layer which is reading data from both the Java and C debuggers,
> which I imagine this would be a lot easier to do if the java
> debugger was implemented using the DSF services framework.
Experiments here are certainly interesting
and encouraged.
> *User customizable views
> This should mostly just be an extension
of DSF
view-model
> functionality, but some more platform support may be required.
> Users should be able to customize the contents in following ways:
> Change the format of labels in Debug
views. The
Debug view is
> especially confusing to our users because it shows labels made up
of
> strings that repeat each other and use unfamiliar concepts, such
as
> launch configuration names and process objects ("the refrigerator
icon").
> Change the layout of views
> Let users hide the process
("refrigerator)
icon, and channel std-io
> through the debug target instead.
> Let users hide the debug target icon in
debug
view, and show threads
> directly below the launch node.
> Let users hide the stack frames in Debug
view
and show a stack trace
> view instead, or use a "quick" view to select the current
stack frame.
> Let users hide register groups in
register view.
> Let users show a "history" node as
a child of variables/registers.
I think most of this is possible with
flexible hierarchy.
> Create custom views with custom content,
such
as
> a stack frame view,
> a history view with a single
variable/register
> debug targets view (as opposed to launch
history
view, i.e. the debug view).
> etc.
The same old problem exists here - i.e. if
the content
adapter is already owned by someone, no one else can extend it.
> *Pin + Clone
> We seem to have talked about this one
for years
on end but we still
> don't have a complete picture on how this should work.
Agreed - it needs more thought. I also agree
that
adding more views to an already crowded perspective is not be the best
approach.
> UI Polishing
> *Better UI for breakpoints and IP
markers in
Editor
> The biggest complaint here is that an
instruction
pointer can
> obscure a breakpoint and multiple breakpoints on the same line
have
> no visual indication. This is more editor work than debugger
work,
> but it's a thorny deficiency in the debugger that has been around
> for a long time. One possible solution may be a dedicated editor
or
> annotation model just for debugging, as opposed to always sharing
> the editor with compiler static analysis, etc.
What would the dedicated editor do
differently? I
think we should push on this in the text framework.
> *Source Lookup UI Improvements
> The source lookup UI is somewhat clunky
by making
the user walk a
> huge dialog tree to accomplish simple tasks. It also lacks
certain
> features such as showing a table of source files from the debugger
> and how they map to host source files.
Ah, you noticed... :-)
Darin Wright
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
|