Skip to main content
Jump to: navigation, search

DSDP/DD/DSF CodingCamp MultiThreadingExcercise

< DSDP‎ | DD
Revision as of 12:56, 9 May 2007 by (Talk | contribs) (Existing Components)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


  • Enable multi-threaded debugging with DSF


Run Control Service

Standard MI implementation
GDB-specific extensions
Existing functionality
  • Basic run control functions (run, suspend, step) for a single thread.
  • Tracking state and generating events for a single thread (running, stopped)
Missing functionality
  • Retrieving list of thread contexts from back end
  • Enabling run control commands for multiple threads (using -thread-select)
  • Tracking state of multiple threads
  • Generating started/stopped events when new threads are discovered or when threads disappear

Command Control Service

Standard MI implementation
GDB-specific extensions
Existing functionality
  • Queueing/Sending of MI commands to back end
  • Receiving responses of MI commands and out-of-band records
Missing Functionality
  • Tracking currently selected thread-id through -thread-select
  • Tracking currently selected frame #, through -stack-frame-select

Command Cache

Existing functionality
Managing command requests for the same piece of data
Caching command results
Coalescing commands which retrieve ranges of data
Missing functionality
Maintaining separate cache data for different contexts
Passing context information for commands on to the Command Control service.

Debug View VM (View Model)

This is the primary client of the IRunControl service, which populates the contents of the Debug view.

Existing functionality
  • Retrieves a single execution context from the MIRunControl service.
  • Retrieves stack frames, and selects top stack frame when suspending and stepping.
Missing functionality
  • Showing a process node (IContainerContext)
  • Retrieving full list of threads.
  • Responding to context-created, context-exited events.
  • For GDB, requesting list of threads to be refreshed.

Reference Code and Documentation

In the CDI package: org.eclipse.cdt.debug.mi.core.command, see commands MIThreadListIds, MIThreadSelect and their corresponding MI documentation. These commands, as well as additional commands for -thread-info, will need to be copied to DSF org.eclipse.dd.dsf.mi.core.command package in order to use within DSF services.

The CDI/MI thread managment: org.eclipse.cdt.debug.mi.core.cdi.model.Target. This implementation uses CLI commands for compatibility with older GDB versions, however it can still be a useful reference.

Design Considerations

Multi-threading functionality spans multiple services. The generation and tracking of execution contexts needs to be added ot the run control service, which is one part of the problem, but all other (data) services need to start tracking data for each thread separately. The spirit of DSF services is to isolate common logic shared by multiple services and to create a separate component to contain that logic.

For multi-threading support, the already-existing cache component needs to be extended in order to track data for multiple execution contexts. The added complication is that the cache component is written to operate on ICommand and ICommandResult interfaces, which are not specific to just MI, but could be used with other back-ends. The challange is to see how the CommandCache and other command interfaces could be extended in order to utilize the generic context interface: IDMContext.

Additionally GDB/MI protocol has a state in form of currently selected thread (via -thread-select) and currently selected stack frame (via -stack-frame-select). In order to avoid sending -thread-select in front of every command (or chaos), the command service needs to track the current state of the protocol and to automatically switch the state whenever a command comes in which needs to operate on a different context than the current one.

Back to the top