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.

1 A Flexible Debug Platform | © 2005 by IBM; made available under the EPL v1.0

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.


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


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


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


Outline

1. View Content Content & labels

2. View Update When & what to refresh

3. User Interaction Driving actions & source lookup


(1) View Content: 3.1

Viewer

Content Provider

Deferred Content

ManagerJob

Standard Debug

Model

Workbench Adapter

getChildren()

place-holder

schedule

getChildren()

getThreads(), etc.

add(child)

replace


View Content: 3.2

Viewer

Model

Content Adapter

Request Monitor

retrieveChildren()

Model Specific API

add(…)

done()

setChildren()


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


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


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”


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


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


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.


(2) View Update: 3.1

Viewer

Model

Model

Standard Debug

ModelEvent Handler

events

refresh()

update()

select()

expand()


View Update: 3.2

Viewer

ElementUpdate Policy

Model

refresh()

update()

select()

expand()

Model Specific API

installs


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


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


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


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


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


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)


(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


User Interaction: 3.1

Debug

View

Selection

Standard Debug

Model

Actions

(instanceof IStep, etc)

Source Lookup

events

Source

Locator

Model

Presentation


User Interaction: 3.2

Debug

View

Selection

Actions

(getAdapter IStep, etc)

Source Lookup

(getAdapter ISourceDisplay)

Debug Context

Manager

Provides context


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


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


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


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


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


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


Implementation Plan

3.2 Milestone 3 (API draft) – November 4th, 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 16th, 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 Towards A Flexible Debug Platform (3.2) State of the World in 3.1 and.

Documents

debug view

flexible debug platform

context view content

debug session slide

active debug context

content adapters

view content content

fires debug events