1 / 5

Wind River Debugger: Advanced Interface Proposal for Enhanced Debugging Capabilities

The Wind River Debugger provides a multi-X external debug server utilizing the gdb/mi ASCII protocol over TCP/IP. This proposal outlines an interface designed to fulfill essential debugging needs, including launching the debugger, sending gdb/mi commands, and handling responses. Key features include command cancelation, asynchronous event listening, and support for various debugger connections. Future enhancements will introduce a command lifecycle listener and extensible backend actions, promoting seamless interactions and performance monitoring while abstracting away backend-specific details for clients.

inigo
Télécharger la présentation

Wind River Debugger: Advanced Interface Proposal for Enhanced Debugging Capabilities

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. WR Debugger Backend Interface Proposal Martin Oberhuber, Wind River Systems

  2. The Wind River Debugger The Wind River debugger is • Multi-X external debug server • gdb/mi ASCII protocol via TCP/IP socket • Standard gdb/mi commands + WR extensions There was a need to • Launch the debugger, or connect to an existing instance • Send gdb/mi commands and wait for response • Allow gdb/mi parallel command execution (multiplexing) • Simple gdb/mi response parsing • Allow command canceling • Listen to gdb/mi asynchronous events.

  3. WR Debugger Backend Interface The proposed interface fulfills these needs. • Not necessarily bound to gdb/mi • Commands and responses can be any Object • Debuggers can be connected in any way (remote socket, local JNI) • connectAsync() performed as an Eclipse Job

  4. Asynchronous Debugger Command Interface

  5. Future Vision / Next Steps • Planned: Debugger Command Lifecycle listener • allows debugger command consistency checks • allows collecting performance data • Planned: Debugger Backend Actions • Extension point based backend action contribution • Example: Actions for download module, unload module, fetch thread list etc. • Benefit: Extensible backends, abstract actions • Benefit: Clients (TM, Launch) do not need to know thebackend specific command details, they only care for the action availability

More Related