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.
I put a star in front of items that
would probably involve platform changes.
-Pawel
P.S. I wrote this up before writing up the multi-context debugging
ideas email, so there may be some repetition here.
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.
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.
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.
*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.
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.
*"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.
*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.
*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.
- 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.
*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.
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.
*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.
|
