1. 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.

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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()

8. 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

9. 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

10. 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”

11. 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

12. 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

13. 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.

14. 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()

15. 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

16. 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).

17. 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)…

18. 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

19. 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

20. 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

21. 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)

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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