Per our discussion in DD meeting this morning, I made up a prioritized
list of bugs that I have filed or updated in platform debug in recent
months. Given that platform resourcing in 3.4 is the primary concern,
I tried to prioritize the bugs based on both relevance and complexity.
I hope this helps and if I can do anything else to help please let me
 _expression_ view actions use getAdapter() to work with
non-standard debug models
This bug is already being considered for 3.4 pending IP review. Fixing
this bug would complete making the Expressions view agnostic of the
debug model being used.
 Extend PresentationContext to save and restore properties.
This is a minor but a very useful feature. Currently, DSF actions
which need to store settings about a given view are not persisted. We
could invent an independent storage mechanism for these settings but it
would be partly redundant and more complicated than the solution
proposed in this bug. The patch itself is actually very
straightforward and it includes a unit test.
 VariablesView should use the ISelection object as viewer
This is also a minor change, which would make the flexible hierarchy
views even more flexible. It modifies the viewer input provider
framework which was introduced in 3.4, so I think it would be nice if
this feature request was considered before the viewer input provider
makes it to a release. DSF probably would not take advantage of this
feature in Ganymede, but it would definitely use it in the future.
 Top index not maintained properly in variables / registers
The patch in this bug is a complex solution to a complex problem. I've
spent about a week and a half developing and testing this patch so I'd
love to see it included in 3.4. Specifically, the patch addresses a
number of race conditions present when saving and restoring the state
of the views. These race conditions are dependent on the frequency of
changes in the viewer input and the amount of state information that
needs to be persisted. The proposed solution adds logic to deal with
partially-restored viewer states and works even when stepping code, or
changing selection in Debug view very rapidly.
As mentioned the patch is fairly large and may require IP review.
Also, Samantha requested to have this bug targeted for 3.4... if that
helps in staffing it.
 Allow multiple debuggers to create breakpoints using the same
This is a fairly extensive feature which may require IP review. It
would address a long standing platform debug design problem (a problem
for Wind River at least) where multiple debuggers cannot use different
breakpoints with the same editor. But beyond that, it would also
create a convenient and a standard mechanism to allow users to create
breakpoints with different options enabled. For example, the patch
includes a feature for JDT, where the user can switch back and forth to
toggle breakpoints which are filtered to the currently selected
It should only take a couple of hours to try out the patches and see
the workflow. While the patch itself is large, it is closely based on
the extension mechanism of the detail panes so I hope it'll be easy to
 "Run to line" action cannot be used with non-standard debug
Run to line adapters have the same problem as toggle breakpoint
adapters, in that only one can be registered per editor. They also
have a larger problem in that they are synchronous interfaces. I
realized the second problem only after I started working on the first
one. I think overall this bug should be deferred till after 3.4, but I
made one small request in the bug: to made the run-to-line
retargetable action check the debug element for the adapter. This way
there could be multiple adapters used with the same editor, but the
asynchronous issue would remain to be looked at later.
 TreeModelLabelProvider does not cancel stale updates.
This is mainly a performance improvment in the flexible hierarchy
viewer. It would also make it easier to implement view data caching in
DSF, but DSF can also work around this problem.
 Need a clarification on usage of IElement*Provider
interfaces with update arrays.
Comment changes, no code.
 Flexible hierarchy provider interfaces should specify that
they will be invoked on the UI thread.
 NPE when closing the Variables view.
NPE bug with a simple fix.
 Add a modules view to the set of standard debugger views.
 Make the detail pane UI support classes a public API.
Both these bugs are mainly to clean up CDT code a bit, and avoid
constantly breaking the CDT build when certain platform debug internal