From: platform-debug-dev-bounces@xxxxxxxxxxx
[mailto:platform-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Wednesday, July 25, 2007
10:52 PM
To: Eclipse Platform Debug
component developers list.
Subject: Re: [platform-debug-dev]
Debugger improvement ideas/ wish list
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