We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byDaniel Warrens
Modified over 2 years ago
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 1 Towards A Flexible Debug Platform (3.2) State of the World in 3.1 and Earlier A debug model provides implementations of specific interfaces (IDebugTarget, etc), and fires debug events in order for the following features to work: View updating Action updating Source Lookup The Debug view is the single source of the ‘active debug context’ and must be open to drive a debugger. The variables view (as others) is hard wired to the selection in the Debug view, and only responds to IStackFrame selections. Actions (step, terminate, etc.), are hard wired to the selection in the Debug view, and respond to debug events.
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 2 Requests from the Community DSDP and PTP projects found the debug platform does not meet their needs and expressed the need for these features: Flexible debug element hierarchy Pluggable view update policies Asynchronous interactions between UI and debug model Flexible view wiring (e.g. input to variables view) Ability to debug multiple sessions simultaneously Meetings resulted in groups being formed to investigate solutions to each of these problems It turns out that all these features are interrelated i.e. A flexible hierarchy is only useful if there is a way to update it
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 3 Stepping Back The goal: The debug platform should support arbitrary debug architectures and implementations of debuggers. One possible implementation of a debugger is the “standard element and event based debug model” that exists today. Hierarchy is based on IDebugTarget/IThread/IStackFrame… View update policy is based on events API is synchronous, but the UI should interact with it in an asynchronous (non-blocking) fashion View wiring is based on stack frame selection Source lookup is based on stack frame selection
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 4 The Proposed Solution A debugger implementation provides a layer of adapters to interact with the platform’s basic views and actions Content and label adapters for views Update policy adapters for views Capability adapters for actions Source display adapters The debug platform provides adapters for implementations of the standard model Existing models continue to work; new models have a choice Additionally the platform provides services for debug context management Ways to retrieve and provide the active debug context that drives a debug session
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 5 Outline 1.View Content Content & labels 2.View Update When & what to refresh 3.User Interaction Driving actions & source lookup
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 6 (1) View Content: 3.1 Viewer Content Provider Deferred Content Manager Job Standard Debug Model Workbench Adapter getChildren() place-holder schedule getChildren() getThreads(), etc. add(child) replace
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 7 View Content: 3.2 Viewer Model Content Adapter Request Monitor retrieveChildren() Model Specific API add(…) done() setChildren()
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 8 Flexible Hierarchy with Asynchronous Interactions Debug platform provides a hierarchy of asynchronous viewers Asynchronous in the following ways: Content retrieval Label generation Setting selection and expansion Update and refresh We provide an abstract viewer and tree viewer Based on JFace structured viewer Table viewer still to come (memory view) Tree viewer supports duplicate elements (variables view) Intend to support table trees
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 9 Content Adapters All content in a viewer is retrieved from adapters on the elements in the viewer, rooted at the viewer input. IAsynchronousTreeContentAdapter retrieveChildren(parent, presentationContext, requestMonitor) isContainer(element, presentationContext, requestMonitor) Features Interaction is asynchronous; model may or may not be Content adapters can provide different content based on context (view) Content is reported back to a request monitor which is a special progress monitor: The request can be cancelled by the content adapter or by the client that made the request
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 10 Presentation Context A presentation context represents the context in which an element is being displayed. The base IPresentationContext is associated with a workbench part Allows for different content in different views E.g. stack frame has children in variables view but not debug view The IPresentationContext can be specialized per view to provide other useful information E.g. whether logical structures are being displayed Design issue: Because adapters are provided for specific contexts, it can make them less re-useable Adapters only know about the contexts they are designed for May need a context to describe “general purpose”
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 11 Request Monitor A specialized IAsynchronousRequestMonitor is used for each specific request to collect the results of a request. E.g. IChildrenRequestMonitor.addChild(Object)/addChildren(Object) A status indicates success or failure Allows for progress reporting and cancellation by the client fulfilling the request or making the request Still investigating ability to retrieve only visible content for a viewer One could imagine a request monitor that provides hints of how many children to retrieve, and also allow the UI to know how many children there are in total
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 12 How to Provide Custom Content? Register IAsynchronousTreeContentAdapters with your debug model elements Caveat: the input to the debug view is the launch manager, which displays all registered launches To display a launch with custom content, you must create your own implementation of ILaunch and register a tree content adapter for it Platform implementation of ILaunch is currently limited to contain IDebugTarget’s and IProcess’s
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 13 Label Adapters are Similar All labels in a viewer are retrieved from adapters on the elements IAsynchronousLabelAdpater retrieveLabel(element, presentationContext, requestMonitor) Features Interaction is asynchronous; model may or may not be Label adapters can provide different renderings based on context A label is reported back to a request monitor which is a special progress monitor that collects text, image, color and font information.
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 14 (2) View Update: 3.1 Viewer Model Standard Debug Model Event Handler events refresh() update() select() expand()
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 15 View Update: 3.2 Viewer Element Update Policy Model refresh() update() select() expand() Model Specific API installs
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 16 Pluggable Update Policies An update policy updates elements in a viewer The default update policy is user driven (none) When the input to a viewer is set, content is retrieved for the root element and children are displayed in the viewer When a user clicks to expand a node, we retrieve more content An update policy allows model driven updates to be applied to a viewer A model provides an IUpdatePolicyFactory adapter for its elements The factory is used to create an update policy for an element in a specific presentation context When an element is added to a viewer, its associated update policy (if any), is installed in the viewer. When the element is removed from the viewer, its update policy is removed (disposed).
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 17 Update Policies The interfaces: IUpdatePolicyFactory createUpdatePolicy(Object, IPresentationContext) IUpdatePolicy init(AsynchronousViewer) dispose() An update policy updates a single instance of a model in a viewer An update policy is installed on a specific viewer Can use the viewer’s API to update its elements refresh(Object), update(Object), expand(ISelection), setSelection(ISelection)…
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 18 Update Policies cont’d An update policy is usually contributed only for the root element in a model (per view) E.g., the update policy for a standard debug model is contributed for IDebugTarget. The update policy listens to events in that target only, and updates all elements in that model An implementer could choose to contribute update policies for each of its elements The debug platform contributes Debug view update policies for: ILaunchManager – updates as launches are registered ILaunch – updates as process or debug target is added IProcess – updates when terminate event is fired
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 19 Mixed Models Update policies are element based via adapters Allows for mixed models I.e. the platform contributes update policies for the launch manager, a launch, and the standard debug target The java debugger contributes an update policy for its additional lock and monitor elements, but it does not need to provide an update policy for the entire model To support mixed models and update policies, an instance of a policy should only update elements in an instance of a model (for example, within a single debug target) Avoids update policies stepping on each other In the old world, there was one update policy that updated all models at once and caused all Debug views to synchronize
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 20 User Configured Update Policies Update policies are an implementation detail We should not expose raw update policies to the user We still want the user to be able to configure an update policy Actions and preferences can be used to configure an update policy or update policy factory for a model For example, you could contribute a view action or preference setting to toggle between ‘always update’ and ‘update every 5 seconds’. This action or preference would modify the way your update policy or update policy factory works We will need an API to update/refresh update policies in a view
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 21 Controlling Selection Collisions An update policy will usually expand and select elements in a viewer that are important – for example, selecting the top frame in a suspended thread. How do we control selections within and across models as they all update in parallel? IModelSelectionPolicy An adapter that resolves selection collisions within a model When a selection is set and there is an existing selection in the model, we can ask the selection policy to resolve a selection conflict with that model When a selection is set and there is an existing selection in another model, we can ask the policy if the existing selection should be considered ‘sticky’ (i.e. override subsequent selections)
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 22 (3) User Interaction The active debug context drives debugging i.e. the selection in the Debug view drives Action enablement (step, terminate, suspend, resume…) Source lookup and instruction pointers The variables and registers that are displayed The context used to evaluate an expression Goals Users would like to be able to debug without the debug view open Users would like to have multiple debug sessions active at once Debug two sessions in different windows or in the same window with multiple Variable views linked to specific contexts Debugger implementers want retargettable debug actions
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 23 User Interaction: 3.1 Debug View Selection Standard Debug Model Actions (instanceof IStep, etc) Source Lookup events Source Locator Model Presentation
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 24 User Interaction: 3.2 Debug View Selection Actions (getAdapter IStep, etc) Source Lookup (getAdapter ISourceDisplay) Debug Context Manager Provides context
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 25 Debug Context Management There can be one active debug context in a workbench window at any given time Usually, this is the selection in the debug view The platform will support IDebugContextProvider’s to be registered with the IDebugContextManager The context manager provides context change notification for a specific window or a specific part within a window A context provider provides the context for a specific part within a window The platform will have a provider that provides a context when there is no Debug view open A Debug view update policy drives the context by setting selection
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 26 Debug Contexts Drive Views and Actions The Debug view is just an IDebugContextProvider By default, the Variables view listens to the active context within its window, and displays content provided by the active context’s content adapter for the variables view Any context can be used to populate the variables view A Variables view could be linked to a specific Debug view The Debug actions are IDebugContextListener’s When the active context changes, the action asks the context for its associated capability adapter (IStep, ITerminate, etc.), and updates based on the current state of the context. When an action is invoked, it disables until the next context change triggers its update
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 27 Actions with Capability Adapters The standard debug actions become retargettable The actions listen to the active context and operate against capability adapters If a client provides a part that is an IDebugContextProvider, that part will drive the debug actions and views when it is active Hope this solves the CDT disassembly view stepping issue The view provides the debug context with appropriate IStep adapter to step in within the disassembly view
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 28 Source Display The active debug context also drives source display via an adapter ISourceDisplayAdapter.displaySource(Object, IWorkbenchPage) The active context is asked for its source display adapter, which is then asked to display source for that context within a specific workbench page. The Debug platform provides a standard source display adapter for IStackFrame’s to maintain backwards compatibility Performs source lookup on the frame Translates the frame to editor id/input using frame’s model presentation Positions editor and displays instruction pointers that are cleared when the frame resumes/terminates
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 29 Summary The debug platform needs to replace all of its element specific and event specific code with a layer of adapters that other models contribute. This way the debug platform can interact with any implementation of a debugger based on these adapters Note that many of the adapters are not debug specific View content, label, update and selection policies are independent of debug (but we own the code) We plan to maintain capability adapters with existing interfaces such as IStep, ITerminate, etc., except that implementors no longer need to fire events in underlying implementations. It’s not clear that we need to replace these interfaces with equivalent ‘asynchronous request’ adapters
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 30 What does this infrastructure enable? Flexible element hierarchies/content per element, per view Customized labels per element, per view Pluggable update policy per element, per view Pluggable source lookup Retargettable debug actions Flexible view wiring Debugging without the debug view Debugging simultaneous sessions in different views
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 31 Implementation Plan 3.2 Milestone 3 (API draft) – November 4 th, 2005 Release first draft and implementation of new APIs Provide implementation of adapters for standard models Existing models continue to work using the new support Provide draft of migration documentation Actually, there should be no migration Documentation describes how to use the new support 3.2 Milestone 4 (API freeze) – December 16 th, 2005 Collect feedback from users of the new API Evolve and solidify the API as required to converge with API freeze
A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0 1 Progress Report - Debug Platform (3.2 M4) State of 3.2 M4 Some Demos.
© 2007 by IBM; made available under the EPL v1.0 | Jan 9 th, 2007 Darin Wright IBM Rational Software Debug Platform 3.3.
Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 Update Policy ~ Where we are in 3.2.
6 Copyright © 2005, Oracle. All rights reserved. Building Applications with Oracle JDeveloper 10g.
Copyright (c) 2005 IBM Corporation; made available under the EPL v1.0 Enhancements in Memory View December 21, 2005.
15 Copyright © 2005, Oracle. All rights reserved. Adding User Interface Components and Event Handling.
Eclipse Debug Views Update Policy. 2 Copyright (c) 2005 IBM Corporation and others. All rights reserved. This program and the accompanying materials are.
Chapter 11 Creating Framed Layouts Principles of Web Design, 4 th Edition.
Suite Suite 2 TPF Software – Overview Binary Editor Remote Scripts zTREX Add-Ins & Project Integration with Source Control Manager.
Flexible hierarchy design proposal. Flexible hierarchy design Goals Allow debug plugins to define their own debug element hierarchy and behaviour.
Januar 2005 S M T O T F L
Chapter 1 The Study of Body Function Image PowerPoint
Eclipse Debug Views Update Policy. 2 Agenda Background Requirements How does it work now? How to make it more flexible?
4 Oracle Data Integrator First Project – Simple Transformations: One source, one target 3-1.
Integrify 5.0 Tutorial : Creating a New Process
From Model-based to Model-driven Design of User Interfaces.
© 2017 SlidePlayer.com Inc. All rights reserved.