1 / 22

Debugger Services Framework (DSF)

Debugger Services Framework (DSF). Device Debugging Project Update by Pawel Piech Wind River Systems, Inc. Agenda. Device Debugging Goals Why another framework? Enabling technologies DSF features Concurrency Services Data Model Migrating to DSF Plans. Device Debugging Goals.

tuan
Download Presentation

Debugger Services Framework (DSF)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Debugger Services Framework (DSF) Device Debugging Project Update by Pawel Piech Wind River Systems, Inc.

  2. Agenda • Device Debugging Goals • Why another framework? • Enabling technologies • DSF features • Concurrency • Services • Data Model • Migrating to DSF • Plans

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

  4. 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 Device Debugging Challenges How DSF fits in...

  5. Enabling Technology: Flexible Hierarchy Viewer Adapter request data Model Specific API Model UI Thread set data update viewer Request Monitor

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

  7. Flexible Hierarchy + Standard Debug Model schedule Job Standard Adapter Standard Debug Model retrieve data send command and wait set data I/O Thread Request Monitor command completed Debugger Back End

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

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

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

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

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

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

  14. Stepping & Stack: Single Step Sequence

  15. Stepping & Stack: Multi-Step Sequence

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

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

  18. Registers View (Components) GDB Custom (DFW) UI Components UI Components Registers View Registers View DSF UI Adapters DSF UI Adapters Registers View Model Adapter Register View Model Adapter DSF Services DSF Services MI Registers DFW Registers MIConnection MIConnection Debugger "back-end" Debugger "back-end" GDB DFW

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

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

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

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

More Related