debugger services framework (dsf)

© 2002 IBM Corporation

Confidential | Date | Other Information, if necessary

© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.

Debugger Services Framework (DSF)

Device Debugging Project Update

by Pawel PiechWind River Systems, Inc.

2© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.

Agenda

Device Debugging Goals Why another framework? Enabling technologies DSF features

• Concurrency• Services• Data Model

Migrating to DSF Plans


Device Debugging Goals

Modify the Eclipse Debug Model Interfaces in order to enable more customized debugger implementations, especially those geared towards the embedded space. (Flexible Hierarchy)

Provide a new Debug Model implementation that takes a more modular approach to connecting debugger back ends into Eclipse. (DSF)

Enhance the debugger views for multi-core and multi-process support and provide specific improvements in those views for embedded development. Multi-core enhancements are proposed for the Eclipse 3.3 release. We are looking at additional view enhancements.

Integrated with the SPIRIT consortium for tooling and debugger data file specification.

Provide the next generation implementation for CDT’s MI debugger.


Device Debugging Challenges

Slow connection to target• Ethernet• JTAG• Serial Port

More visibility into target hardware• On-chip Peripherals• Processor Cache• Flash Memory• Tracing • Hardware Breakpoints

Varied target hardware architectures• Multiple Cores/CPUs/DSPs• Memory Models

Strict Concurrency Model• Complex caching techniques• Exact control over when and what data is retrieved from target

Modular Debugger Implementation• Selective re-use of a standard implementation• Custom services can be written to interact with custom hardware

Decoupled view layout from data model• Layout and content of views easily customized• (Beyond 3.3) Layout customized by users

How DSF fits in...


UI Thread

Enabling Technology: Flexible Hierarchy

Viewer

Model

Adapter

Request Monitor

request data Model Specific API

set data

update viewer


Flexible Hierarchy(notes) Adapters obtained by the view based on the data object in the viewer and the

IAdaptable mechanism Adapter methods are asynchronous, meaning that the adapter takes the "request

monitor" as an argument, and it can perform the operation on any thread with any kind of delay.

There are separate adapters for every aspect of viewer operation:• retrieving children of a node• retrieving label of a node• translating model events into viewer updates• determining list of columns in viewer• creating cell editors• determining whether selection request should be overridden• displaying source based on selection in Debug view


I/O Thread

Job

Flexible Hierarchy + Standard Debug Model

Standard

Adapter

Request Monitor

set data

Standard Debug

Model

retrieve data

schedule

DebuggerBack End

send commandand wait

commandcompleted


Flexible Hierarchy + Standard Debug Model(notes) There is a full array of adapters and supporting classes already written for all the

objects of the Standard Debug Model. These classes are still internal to Platform, but are likely to be made public at least to some extent.

The implementation has a performance problem due to the fact that a separate job is created for every label and content retrieval, but this is going to be addressed soon (bug 143711).

The remaining performance bottleneck is the request-wait-return pattern for communicating with the debugger back end. Even though a separate thread is used for I/O (for CDI), the calling Job is blocked until the command is completed.

The Standard Data Model is accessed by many job threads, hence its implementations must be thread safe and they must synchronize access to their state data.


I/O Thread

DSF Executor Thread

Flexible Hierarchy + DSF

DSF

Adapter

Request Monitor

set data

request data

return data

DebuggerBack End

sendcommand

commandcompleted

DSF Services


Other Enabling Technologies

OSGi• Robust services framework

Java 5• java.util.concurrency - extensive set of utilities helped implement a stable and

complete concurrency model in DSF• generics - helped simplify and reduce number of objects in asynchronous interfaces• annotations - used by DSF service event framework


Concurrency Model

Rules• Single thread for communication between services• No blocking calls on the shared thread

Practical Effects• Predictable system state when executing in executor thread• Synchronization accomplished through thread confinement

• no race conditions, • no synchronized blocks

• Synchronous access to services' state data• Asynchronous methods are required for all other data retrieval• Background threads are required for external I/O and long running operations• Difficult to step through with debugger

• Tracing tool needs to be developed to aid debugging


Case study: Stepping and Stack

Requirements• Stepping speed should be limited only by the target

• Cursor position and instruction pointer should update after every step

Design challenges• Stack data is usually retrieved using -stack-list-frames, which is expensive• Top stack frame information is also included in the stopped event• To achieve maximum speed, -exec-next should be executed as soon as the stopped

event is received

Notes• Step Queue service is used to queue up step requests from UI• Sequence highlighted in red is the dispatching of the Suspended event from the Run

Control service, which occurs within a single execution cycle • Sequence highlighted in blue is the debug view retrieving the full list of stack frames,

it fails in the multi-step sequence because the target is running


Stepping & Stack: Components

Run ControlStack

GDB

Debug View

View Model Adapter Source Lookup Adapter

Editor

UI Components

DSF UI Adapters

DSF Services

Debugger "back-end"

Step Queue

Step Action Adapter

Step Action


Stepping & Stack: Single Step Sequence


Stepping & Stack: Multi-Step Sequence


Debugger Services

Build on top of OSGi services framework Service interfaces make up a public API of a debugger implementation Clear dependencies between modules

• Dependencies dictate the startup and shutdown order of the services

• Startup order dictates the priority for service event listeners

Extending debugger implementation• Adding new services to implement custom functionality

• Replacing selected services with custom impementation


Case Study: Registers View

Custom debugger implementation (DFW)• Standard MI protocol for run control, stack, etc.• Custom protocol for register data

Goals• Reuse as much of DSF-MI implementation as possible

Notes• The only service that has to be modified/replaced from the standard MI

implementation is the Registers service


Registers View (Components)

DSF Services

MIConnection

MI Registers

GDBDebugger "back-end"

GDB Custom (DFW)

Registers View Model AdapterDSF UI Adapters

Registers View

UI Components

DSF Services

MIConnection

DFW Registers

DFWDebugger "back-end"

Register View Model AdapterDSF UI Adapters

Registers View

UI Components


Decoupled View Layout - Data Model

Flexible Hierarchy already allows customization. What's left?• Framework designed specifically to work with DSF Services• Simplified API over the standard adapter interfaces• Simplified mechanism for processing target events and generating model deltas• Customizing view layout at "on the fly"

Possible contribution to Platform• Implementation is currently highly-dependent on DSF concurrency and services

model• More design/implementation/testing still needed


Migration and Compatibility with CDI Common components

• Editor/Disassembly• Breakpoints • Source Lookup

CDI• It is possible to implement a CDI debugger using DSF Services• But, it's not really practical because implementing a synchronous API on top of an

asynchronous API defeats the purpose of the former• A significant amount of work• If needed for compatibility, DD project is seeking help from community for this effort

Platform's Standard Debug Model• Can and will be implemented for Europa release• Best bet for 3rd party tools and backward compatibility

CDT extensions to Standard Debug Model• Some interfaces need to be implemented to work with CDT disassembly view• Full implementation may be possible for Europa release, depending on staffing


Goals & Planning

Europa• 0.9 Release• Full MI implementation with functionality equivalent to CDI• Complete APIs, but not yet finalized• Updating the build process based on information from build symposium

Beyond Europa• Finalize APIs• Laundry list of features

Early Adoption (before Europa release)• Will require close collaboration and lots of patience• Would definately help improve DSF architecture and quality• Wind River will start adopting DSF to the commercial product starting in the Fall


Resources

Device Debugging Project http://www.eclipse.org/dsdp/dd/index.php DSF Documentation http://dsdp.eclipse.org/help/latest/index.jsp Flexible Hierarchy Tutorial

http://www.eclipsecon.org/2006/Sub.do?id=58&not_accepted=0

http://www.eclipse.org/dsdp/dd/index.php

http://dsdp.eclipse.org/help/latest/index.jsp

http://www.eclipsecon.org/2006/Sub.do?id=58&not_accepted=0

debugger services framework (dsf)

Documents