Transcript Debugger Services Framework (DSF)

Debugger Services Framework (DSF)
Device Debugging Project Update
by Pawel Piech
Wind River Systems, Inc.
Confidential | Date | Other Information, if necessary
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
© 2002 IBM Corporation
Agenda




Device Debugging Goals
Why another framework?
Enabling technologies
DSF features
•
Concurrency
•
Services
•
Data Model
 Migrating to DSF
 Plans
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
2
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. Multicore 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.
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
3
Device Debugging Challenges
How DSF fits in...
 Slow connection to target
• Ethernet
• JTAG
• Serial Port
 Strict Concurrency Model
• Complex caching techniques
• Exact control over when and what data is
retrieved from target
 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
 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
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
4
Enabling Technology: Flexible Hierarchy
request data
Adapter
Model Specific API
Viewer
set data
Model
UI Thread
update viewer
Request Monitor
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
5
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
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
6
Flexible Hierarchy + Standard Debug Model
schedule
Job
Standard
Adapter
retrieve data
Standard Debug
Model
send
command
and wait
set data
I/O Thread
Request Monitor
command
completed
Debugger
Back End
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
7
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.
DISCLAIMER: POSSIBLE TO CIRCUMVENT
 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.
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
8
Flexible Hierarchy + DSF
request data
DSF Executor Thread
DSF
Adapter
DSF Services
return data
set data
send
command
I/O Thread
Request Monitor
command
completed
Debugger
Back End
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
9
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
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
10
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
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
11
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
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
12
Stepping & Stack: Components
UI Components
Step Action
Debug View
Editor
DSF UI Adapters
Step Action Adapter
View Model Adapter
Source Lookup Adapter
DSF Services
Step Queue
Stack
Run Control
Debugger "back-end"
GDB
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
13
Stepping & Stack: Single Step Sequence
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
14
Stepping & Stack: Multi-Step Sequence
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
15
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
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
16
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
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
17
Registers View (Components)
GDB
Custom (DFW)
UI Components
UI Components
Registers View
DSF UI Adapters
DSF UI Adapters
Registers View Model Adapter
DSF Services
Registers View
MI Registers
Register View Model Adapter
DSF Services
MIConnection
Debugger
"back-end"
GDB
DFW Registers
MIConnection
Debugger
"back-end"
DFW
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
18
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
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
19
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
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
20
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
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
21
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
© Wind River Systems, released under EPL 1.0. All logos are TM of their respective companies.
22