Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] DD Priorities for Platform Debug bugs for 3.4

Thanks Pawel,

I applied patches for two of the minor fixes (213719 and 213609), and we'll use this as a guide to tackle the others that are more involed.

> [209883] _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.

We'll fix this in 3.4 pending IP approval.

> [213069] 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.

Will consider for 3.4.

> [166155] VariablesView should use the ISelection object as viewer input.
> 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.

Please see question on bug.

> [188704] Top index not maintained properly in variables / registers view.
> 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.

Will consider for 3.4. Will likely need IP approval due to size of fix.

> [212316] Allow multiple debuggers to create breakpoints using the same editor.
> 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 thread.  
> 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 digest.

Will need IP approval, but still needs more evaluation before we consider for 3.4.

> [213074] "Run to line" action cannot be used with non-standard debug models.
> 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.

Deferred, but we might consider asking the target for the adapter in 3.4, before checking the editor.

> [210027] 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.

Needs more evaluation before considering.

> [213609] Need a clarification on usage of IElement*Provider
> interfaces with update arrays.
> Comment changes, no code.


> [213629] Flexible hierarchy provider interfaces should specify that
> they will be invoked on the UI thread.
> Past 3.4


> [213719] NPE when closing the Variables view.
> NPE bug with a simple fix.


> [211158] Add a modules view to the set of standard debugger views.
> [210466] 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 APIs change.


Back to the top