Bugzilla – Full Text Bug Listing
| Summary: | Feature request: More flexible debug hierarchy | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Cameron Stevens <cameron.stevens> |
| Component: | Debug | Assignee: | Luc Bourlier <eclipse> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | eclipse, eharris, stevenyj, turnham |
| Version: | 2.1.2 | ||
| Target Milestone: | 3.1 M3 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
| Bug Depends on: | 44724 | ||
| Bug Blocks: | 75280 | ||
Need to investigate impact for 3.0 Deferred for post 3.0 consideration. Consider in 3.1 In order to support a flexible presentation/hierarhcy in the debug view, we intend to support a "debug view content providers" extension point. The extension will contribute an ITreeContentProvider for a debug model, which will be consulted to retrieve children for debug elements from that model. The root element will still be an IDebugTarget, but past that, the content provider can provide an arbitrary structure. The Java debugger will use this feature to support bug 75280. I have released an initial implementation to HEAD. * added debugViewContentProviders extension point and schema * added DefaultDebugViewContentProvider class to org.eclipse.debug.ui * added "empty" content provider/extension for Java debugger (JavaDebugContentProvider) * enhanced LaunchViewContentProvider to delegate to model specific content providers * modified LaunchConfigurationPresentationManager to load/manage debug view content provider extensions Issue: the content provider is based on debug model, which precludes debug models that wrapper a model to inherit the content provider specific to a model. Erin, we have added this feature (pluggable debug hierarchy) to the debug platform, to allow debug models to provide custom element hierarchies in the debug view. Rather than changing the model, we have left this as a presentation issue. For example, the use case we have with the Java debugger is to integrate extra information into the debug view to show the monitors (locks) owned by a thread. The locks are shown as children of a thread (before stack frames), whem the "Show Monitors" option is turned on in the debug view. The issue is that the feature only works for non-wrappered debug models, since the content provider is contributed for a specific debug model. The elements displayed are not "core model elements", but rather UI elements representing the locks. Do you think models that wrapper our Java debugger will want/need to display the same information? In general, wrapper debuggers would want to display this information as well since their purpose is to add functionality to the Java debugger without losing any of the features that it already has. I'm not sure we can make this work for wrappering models - as we would end up mixing elements from different debug models. Currently, everything in a "java adapter" wrappers the underlying Java debug model. For example, our content provider retrieves children for IJavaThread's, and it returns the monitor information elements as well as IJavaStackFrames. You would need a mixed list of the monitor elements and your wrappering stack frames (and our model knows nothing of the wrapper). One possible solution is to contribute a content provider for an adapter - i.e. for elements that provide and adapter of a specific type such as IJavaThread. Needs more investigation. Fixed. Changed the extension point to contribute a content provider for arbitrary elements in the debug view based on an enablement expression. The extension point must have an id that uniquely identifies it. Changed the Java contribution to be applicable to objects that have IJavaThreadAdapters or are instances of IJavaMonitorElement (which I added as a tagging interface for our extra debug elements). Changes in LaunchConfigurationPresentationManager, LaunchViewContentProvider, JavaDebugContentProvider, (added) IJavaMonitorElement, JavaContendedMonitor, JavaOwnedMonitor, JavaOwningThread, JavaWaitingThread, plugin.xml, and schema for debugContentProviders. Will file a new bug to update the monitor manager/elements to have back pointers to the apporpriate parent element (from a wrapper model). Please verify, Luc. This support is going to change to support deferred content generation in debug views. To support background content in debug views, the debug view has changed to use a workbench content provider via IWorkbenchAdapters and IDeferredWorkbenchAdapaters. I removed the debugViewContentProviders extension point. Instead, models wishing to provide custom content can provide IWorkbenchAdapters and/or IDeferredWorkbenchAdapater for appropriate elements. The Java debugger provdies an IDeferredWorkbenchAdapter for IJavaThread to provdide extra monitor information, as well as adapters for its monitor information elements. Fixed. Please verify, Luc. (There are many changes) @see DeferredContentProvider, and hierarchy of DeferredMonitorElement. The java debugger provides IDeferredWorkbenchAdapters for Java Thread and the monitor information elements. I will file a new bug to address the issue of displaying the monitor information for models that wrapper the java debugger (which is a seperate issue - support for a flexible hierarchy now exists). Also see DebugElementWorkbenchAdapter, a public class that can be subclassed by adapters provided by other debug models. Verified. |
Currently, the debug model is restricted to something like: Launch Target Thread Stack Frame It would be nice to have a little more flexibility. The device I am targeting has a more hierarchical structure, and it would be nice to reveal this in the Debug view. In my case, I would like to express something more like: Launch Target 1 Chip 1 Core 1 Node 1 Thread 1 Stack Frame 1 Perhaps if IDebugElements were self-aggregating, this would be sufficient.