Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "DSDP/DD/DSF CodingCamp MultiThreadingExcercise"
(→Existing Components) |
(→Command Cache) |
||
Line 38: | Line 38: | ||
: Maintaining separate cache data for different contexts | : Maintaining separate cache data for different contexts | ||
: Passing context information for commands on to the Command Control service. | : Passing context information for commands on to the Command Control service. | ||
+ | |||
+ | == 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. |
Revision as of 00:48, 9 May 2007
Contents
Goals
- Enable multi-threaded debugging with DSF
Existing Components
Run Control Service
- Interface
- org.eclipse.dd.dsf.debug.service.IRunControl
- Standard MI implementation
- org.eclipse.dd.dsf.mi.service.MIRunControl
- GDB-specific extensions
- org.eclipse.dd.dsf.mi.service.GDBRunControl
- 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
- Interface
- org.eclipse.dd.dsf.debug.service.command.ICommandControl
- Standard MI implementation
- org.eclipse.dd.dsf.mi.command.AbstractMIControl
- GDB-specific extensions
- org.eclipse.dd.dsf.mi.commandGDBControl
- 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
- Implementation
- org.eclipse.dd.dsf.mi.service.control.MICommandCache
- 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.
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.