Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

CDT/Obsolete/MultiCoreDebugWorkingGroup

< CDT‎ | Obsolete
Revision as of 15:29, 26 October 2010 by Dalexiev.ti.com (Talk | contribs)

Multi-Core Debugging Working 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 should be held on a regular basis to discuss progress, issues, features, tasks, etc. Schedule and phone numbers will be posted once they are available.

Suggested features

  1. Grouping of debug view elements
  2. Debug operations (step, resume) on groups
  3. Hiding of debug view elements
  4. User-selectable Debug View layouts

Current issues

  1. DSF sees to have a limitation where it only accepts a single level of IContainerDMContext.

Multi Level Hierarchy in the Debug View using DSF

Currently Platform Flexible enabels 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 following use cases:

User cases:

  • UC1:

The debug view shows hierarchy "core – process - thread" The user can switch the hierarchy to show "process – thread – core"

  • UC2:

The debug view shows hierarchy "core – thread – process" The user can hide and show all "core" nodes. All "thread" nodes will appear as children of the launch node. The user can hide specific core from the hierarchy. Its "thread" nodes can either hide, or they can become children of the launch node.

  • UC3:

The user of a multicore system can hide and show the boards the cores / devices / connections the core belongs to.

  • UC4:

The user can create custom groups that he can use for synchronized stepping / running / halting.

  • UC5:

The user can hide in the debug view all threads and processes with names that matches a specific pattern.

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 this page.


Related Information

Original CDT Multi-Core wiki page
Pin & Clone effort

Back to the top