Hi Pawel,
The DSDP/DD meetings have been very
useful and productive in terms of the Platform improvements. Our new
commercial product is based on the flexible hierarchy and uses most of the other
new features the Platform provides and it seems to work very well. It is
definitely +1 from me to resume the face-to-face/phone meetings. I would be
very interested to attend such a meeting and I believe that many people who are
planning to attend the CDT meeting would be interested too. So
why not to use the CDT meeting for this purpose? As far as I remember
Doug Schaefer was planning something like that. A planning phone
meeting can be held in mid August.
Thanks,
Mikhail Khodjaiants
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
--
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
|