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.
CDT/Obsolete/MultiCoreDebugWorkingGroup
Contents
Multi-Core Debugging Work Group
This page documents the activities of CDT's Multi-Core Working Group. This group aims to bring together different people from the community to jointly work on developing multi-core debugging for CDT. The group was first proposed at the CDT Summit 2010 and the suggestion was well received.
Any one interested in helping in this effort is welcome to follow or join the group.
Conference calls
Conference calls are held on a regular basis to discuss progress, issues, features, tasks, etc.
Currently, we have conference calls every two weeks. The next call info is:
- Tuesday November 30th, 2010 at 11 a.m. Ottawa time
- Canada and US Toll Free - (877) 748-5444
- International Numbers
- Conference ID - 620 4947
- Upcoming agenda and previous minutes
Multi-Core Debugging
Although this effort covers the debugging of target with multiple cores, we use the term Multi-core debugging in much wider sense. Multi-core debugging is meant to describe the simultaneous debugging of multiple cores, processes, threads, or other objects which are represented in standard debugger views.
Suggested features
- Grouping of debug view elements
- Debug operations (step, resume) on groups
- Hiding of debug view elements
- User-selectable Debug View layouts
- Pin and Clone of debugging views
- Grid view
Features already completed
List of features that have already been implemented.
Use-cases
Description of the set of use-cases proposed to be covered.
Current issues
List of current issues affecting this effort.
Multi Level Hierarchy in the Debug View using DSF (Dobrin)
Currently Platform Flexible enables the debug view to show any hierarchy of objects.
DSF currently has defined two data model interfaces IExecutionDMContext and IContainerDMContext
and two view models classes: AbstractThreadVMNode and AbstractContainerVMNode.
I would like to explore these interfaces and the classes using them to deliver the following features:
- Containers can be recursive - each container can have its own stack and/or other child containers.
- The user should be able to filter and show container nodes or container types.
- The user should be able to group and ungroup container nodes or container types.
- Filtering and grouping nodes can be both with the involvement of the back end debugger or not.
- The user should be able to change the way the contaniers are presented in the debug view without changing the container's hierarchy.
- The containers can have types so the user can filter or group containers by container type.
I believe these features are driven from the use cases of section 4 of the use case page, called Debug View hierarchy operations.
Currently I know of two Bugzilla entries related to the idea:
Bug 240208 A single VMNode should represent all execution levels
Bug 306868 DefaultVMModelProxyStrategy does not generate proper delta with recursive VM nodes
I think we can reuse the first one to further discussion on the topic. To discuss requirements and use cases we can use the use case page.
Notes
- Many of the ideas expressed here are taken from the Original CDT Multi-Core wiki page. This page has been replaced with the Multi-Core Working Group pages.