[platform-debug-dev] debug view features for embedded debugging

[Pawel Piech <pawel.piech@xxxxxxxxxxxxx>]

Hi All,
I'm part of the team implementing the debugger at Wind River for
embedded development.  And we would like to add a few features that
would make the debug view more usable for our implementation.  So we'd
like to know how receptive the platform debug development team would be
to adding these, and what would be the best way to go about it.
Specifically, there are some of the features we'd be interested in adding:

1. A "double-click to open editor" preference option.  Currently the
debug view opens the editor for selected stack frame on every selection
change, and conversly, on every suspended event.  This is desirable most
of the time, but in certain situations, like when running scripts, this
can be very disruptive.  It makes editing impossible and working with
some views annoying, because when the debugger opens an editor,
maximized viewa are un-maximized.  We would like to add a mode where the
user has to double-click a stack frame in order to open the editor.

2. DebugEvent.SUSPEND_RESUME event.  In embedded debuggers especially
retrieving and displaying data can be very expensive, especially when
user is stepping and is only interested in seeing the IP move on the
screen.  To address this, we would like to add a debug event that would
only be intended for the debug view, in order to update the IP
annotations.  I haven't fully thought through what other implications
this might have so another method (rather than new event) of achieving
the same ends might be more appropriate.

3. Preference option to retrieve only one, or fixed set of stack frames
on a suspended event.  Retrieving a full stack trace can be very time
consuming, and is often not necessary.  We would like to add a mode
where the debug view only shows the top frame, or a limited number of
frames, then it shows the full stack trace when requested by the user.
It is possible implement this feature without modifying the debug view
at all, but it's not particularly clean.

4. Multiple selection spaces in debug view.  The purpose of this is to
make it easier to debug multiple processes, threads, etc, at the same
time.  This is a very wide-reaching feature, but the basic idea is to
have multiple selections being maintained by the debug view, and have
other views (expression, registers, memory, etc) listen only to one of
the selections.  This also implies having multiple instances of these
views.  In our case we differenciate the selection spaces by color, so
we paint all the debug elements of the same selection space and the
views listening to it, all the same color .  Once again, we have
implemented this without modifying the debug view, but it is not very
clean, and there's some features that we simply cannot make work.

Thanks for your feedback in advance.
Cheers
Pawel