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/DebugElementsGrouping

Groups of Debug Elements

This feature is dependent on: Multi Level Hierarchy in the Debug View

List of debuggers this feature is being tested with

  • Ubuntu: GDB 7.2 – non-stop mode.
  • Ubuntu: GDB 7.2 – stop mode.
  • Windows: Cygwin with GDB 6.8 – stop mode.
  • Windows: MinGW with GDB 7.2 – stop mode.

Definitions

  • Stop mode debugger – when the user suspends one thread all threads become suspended.
  • Non-stop mode debugger – each thread can be suspended independently of the other threads.
  • Container node in the debug view – it can be a user group or a process.

Supported Use Cases

Main cases

UC1.1 Grouping threads

  • The user selects multiple thread nodes in the debug view, then selects context menu “Group”.
  • A groups node will appear in the debug view between the process node and the selected thread nodes.

UC1.2 Recursive groups.

  • The user can select groups and threads and group them together.
    • A group will be created above their most common grandparent.

UC1.3 Processes from the same debug session cannot be grouped – “Group” command will be disabled.

UC1.4 Elements from different debug sessions cannot be grouped – “Group” command will be disabled.

UC1.5 Ungrouping.

  • The user selects a group in the debug view then selects context menu “Ungroup”.
    • The group will be removed from the Debug View.
    • The items in the group (threads or groups) will become immediate children of the parent of the removed group ( process or another group).

UC1.6 Ungrouping multiple groups at the same level with the same command.

UC1.7 Ungrouping multiple groups from different levels with the same command.

UC1.8 New threads created by the program will be added to the process, not to a group.

UC1.9 If a thread that belongs to a group is terminated by the user program it will disappear from list of childrent of the group it used to belong.

UC1.10 The user should be able to debug more than one process in GDB and created separate groups in each of the processed.

UC1.11 If all thread belonging to a group are terminated the group will be empty.


Auto expansion and selection when thread suspends.

UC2.1 Auto expansion and auto selection on suspended threads

  • A thread belonging to a group or a recursive group is suspended due to a breakpoint or other reason.
    • All processes and recursive groups and the thread node will auto expand
    • The top stack frame from that thread will be auto selected.

UC2.2 Make sure when stepping the stack collapses if the thread(s) is still running after 1 second.

  • The user debugs a program that has sleep(5).
  • Select the top stack frame and step over the line that has "sleep(5)".
  • The stack frames should disappear.
  • Select the launch node.
  • After few seconds when the thread is suspends it should select the top stack frame.


Execution state

UC3.1 Execution state of a container ( process or a group)

  • If all elements of a container are suspended its icons will have the Pause decorator.
  • If at least one element of a container is running the icon will not have the Pause decorator.

UC3.2 Suspend command ( applies for process and groups of any level)

  • When a container is selected the Suspend command will be enabled if at least of its child element is running.
  • When a container is selected the Suspend command will be disabled if all child elements are suspended.

UC3.3 Resume command ( applies for process and groups of any levels)

  • When a container is selected the Resume command will be enabled if at least one child element is suspended.
  • When a container is selected the Resume command will be disabled if all child elements are running.

UC3.4 Suspend command for non-stop mode debuggers

  • If the user selects the Suspend command on a container all children of that container should become suspended.
  • No other threads, groups or processes should change their running state.
  • The icon of the container and all its children should show suspended and have the Pause decorator.
  • Some threads may expand and the top stack of one child thread will become selected.

UC3.5 Suspend command for stop mode debuggers

  • If the user selects the Suspend command on any nodes ( process, group or thread) all nodes associated with that process will become suspended.
  • The icon of all nodes ( process, groups, threads) should change to suspended and have the Pause decorator.
  • Some threads may expand and the top stack of one child thread will become selected.

UC3.6 Resume command for non-stop mode debuggers

  • If the user selects the Resume command on a container, all children of that container should resume.
  • No other threads, groups or processes should change their running state.
  • The icons of the container and all its children should not have the Pause decorator.
  • The stack frames of all threads inside that container or its groups will not be displayed anymore.

UC3.7 Resume command for stop mode debuggers

  • If the user selects the Resume command on any node, all nodes of that process should resume.
  • The icons of all nodes will not have the Pause decorator.
  • The stack frames of all threads inside that container or its groups will not be displayed anymore.

UC3.8 Empty group

  • If a group becomes empty due to all its threads are terminated:
    • It will be consider running - no Pause decoration in the debug view.
    • The Suspend and Resume button will be disabled.


Miscellaneous

UC20.1 Stack frames will be preserved after grouping threads

  • The user selects few suspended threads and groups them.
  • The user selects and expands one of the grouped threads.
    • The stack frame should be correct (same as before the grouping).
    • The variables view should show correct data for the top stack frame (same as before the grouping).

UC20.2 Make sure a top stack frame is selected when a debug session starts

UC20.3 Make sure terminate works after stepping a group (no outstanding request monitors)


To be tested

Future use cases

  • Grouping processes within the same debug session.
  • Grouping threads from different processes within the same debug session.
  • Adding a node to a existing group.
  • Renaming group.
  • Persisting groups between debug sessions.
  • Adding a breakpoint to a group.
  • Groups belonging on the back end.

Design bits and pieces

Which debuggers can have grouping feature?

By default grouping of debug elements is disabled. The command group “Debug View Layout” needs to be enabled from the perspective customization dialog.

The grouping feature is available only for DSF debuggers that implement IExecutionContextTranslator. Currently GDB is the main drive for the grouping feature. Its implementation is available from the latest patches in https://bugs.eclipse.org/bugs/show_bug.cgi?id=336876 Even after applying the patch the user has to set an environment variable GDB_DEBUG_VIEW_GROUPS to 1 to use the feature. Once the basic features in the GDB implementation is acceptable and commited a second DSF debugger will also be integrated. That will help to extract the common pieces from GDB-DSF to DSF.

The UI actions are contributed in CDT UI so in theory CDT-CDI can also implement grouping on their own. Considering that the CDT-CDI is based on fixed hierarchy and it is mostly in maintenance mode I doubt anyone will go ahead and implement groping there.

Currently the IExecutionContextTranslator interface is experimental. It is defined as minimal functionally so the group and ungroup command can be hooked up as soon as a DSF debugger implements that service.

What does the back end control (will control)?

Currently GDB doesn’t have the concept of groups on the back end. The user defined groups will iterate through its threads to run/suspend/show running state, etc. With other DSF debuggers that behavior can be different – the groups can belong to the back end and the back end can dictated how a resume / suspend operation is to be executed, how will the running state be aggregated.

Recreating the execution context under different parent’s hierarchy.

When we group execution contexts we recreate the execution context again with one if its immediate parents – the newly created group. Since the parents are part of the object’s identity that means that clients that cache the execution context will need to point to the new objects after the group is created. Alternatively instead of caching the execution object it is better to cache the real object it represents – in the GDB case this is the ThreadDMcontext. GDBRunControl_7_0_NS is an example of component that has been reworked to cache MIThreadRunState against the IThreadDMContext instead of the IExecutionDMContext. To unify what should the client cache instead of the execution context I introduced the function IMIExecutionContextTranslator.getStableContext(). Also the CommandCache is replaced with a new class MICommandCache that underneath calls IMIExecutionContextTranslator.getStableContext(). If DSF components need to change what they cache this function will move up IExecutionContextTranslator, no need yet. Alternative approaches have been discussed at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=336876#c24

Introducing IRunControl3.

IRunControl has synchronous methods isSuspended() and isStepping(). In order for the group to figure out if any of its children is stepping or suspended it needs to get the list of its children which is an asynchronous API. Therefore DSF debuggers that support grouping also need to implement IRunControl3 which just define isSuspended() and isStepping() in asynch way. All places in DSF that use these function should switch to using the asynch version, at least in the case of the container DM context.

Propagating the changes in debug view layout.

Considering that grouping is part only of bigger feature – debug view layouts currently there is only one event introduced to communicate that there was a debug view layout change. As introduction of more feature ( hiding, full layout ) more specific event can be added. The event IContainerLayoutChangedEvent inside the interface IMIExecutionContextTranslator.

Introduction of AbstractExecutionContextVMNode

There are many similarities between AbstractContainerVMNode and AbstractThreadVMNode. AbstractExecutionContextVMNode is a base class that will host the shared functionally. Currently the function there are not hooked up to the immediate derived abstract classes, but only by the concrete instance in GDB – ContainerVMNode and ThreadVMNode. As other DFS debugger start implementing grouping this class may enclose more common functionality.

Changes to DefaultVMModelProxyStrategy to support generating deltas for recursive VM Nodes.

The changes are 100% compatible. Only if the user calls setAllowRecursiveVMNodes() the new implementation will take effect. Originally DefaultVMModelProxyStrategy didn’t accept recursive container for generating deltas, even though they are accepted and supported by AbstractDMVMProvider for viewing. The approach I took is to support recursive container in delta generation is to have the VMNodes to generate level by level its deltas instead of one the whole delta at once. That required changes in indentifying which is the correct context for each of the events.


Comments and Discussions

Bug 336876 Grouping of Execution Elements for DSF debugger feature

Back to the top