Hi Darin,
If discussing platform improvements in context of the DD project still
works for you, it'll certainly work for us :-) When I finally have
time to work on the DD project plan I'll make a home for these ideas on
DD Wiki. Even though, the specific work items may very well end up in
platform, CDT, or TM projects.
Cheers,
Pawel
Darin Wright wrote:
Currently, the debug team is not
planning
to attend the CDT summit due to other commitments.
For now, I would suggest to have
discussions
about the work list below in the context of the DD project as we have
done
in the past. It may lead to something separate for specific work items.
Darin Wright
Eclipse Debug Lead,
Rational Team,
IBM Canada
I don’t think it needs to
be a parallel session. Debug should be and needs to be a hot topic for
the next CDT release. All of the issues you raise are things are things
the entire CDT community has struggled with and we would all benefit
from
contributing to. I just want to make sure the CDT community is plugged
into this activity. As you mention this stuff does go beyond device
debugging.
Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com
From:
platform-debug-dev-bounces@xxxxxxxxxxx
[mailto:platform-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Gaff,
Doug
Sent: Thursday, July 26, 2007 10:02 AM
To: Eclipse Platform Debug component developers list.
Subject: RE: [platform-debug-dev] Debugger improvement ideas/ wish
list
Doug - sounds good, but I think
Mikhail
might also be requesting a parallel session for debug-related
discussions
at the CDT summit, or at least a day dedicated to it. Pawel and
Dominique
definitely want to update the CDT community on the DSF GDB
implementation,
but the list below goes well beyond that.
Darin, I think the question for you is
this:
Do you want to have discussions about the work list below in the
context of the DD project as we have done in the past, or do you want
to
start up something separate that focuses on the Eclipse Debug Platform
team?
From Wind River’s perspective, it will
be the same engineers from the DD project also helping with these tasks
and earning their stripes in the Debug Platform team. But the
technical
focus of the list below goes beyond Device Debugging, so I could either
way on meeting organization. I suggest we just do whatever is
convenient.
From:
platform-debug-dev-bounces@xxxxxxxxxxx
[mailto:platform-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug
Schaefer
Sent: Thursday, July 26, 2007 9:42 AM
To: Eclipse Platform Debug component developers list.
Subject: RE: [platform-debug-dev] Debugger improvement ideas/ wish
list
Hey guys,
I think it would be great
if
we could get an update from these discussions and from the platform
debug
team in general at the CDT Summit in September. The CDT obviously
relies
on everything that happens there. Details on the conference are here:
http://wiki.eclipse.org/CDT/summitfall2007
It would be great if a
platform
debug committer could attend. Thanks!
Doug Schaefer, QNX
Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com
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
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
|