CDT/Obsolete/MultiCoreDebugWorkingGroup/DebugElementsGrouping

Groups of Debug Elements

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

List of debugger this feature is currently 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 suspended one thread all thread become suspended.
• Non-stop mode debugger – each thread can be suspended independently.
• Container node in a debug view – it can be 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 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 multiple debug session 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 group ( process or another group).

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

UC1.7 Ungrouping multiple groups at different level from different levels.

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

UC1.9 If a thread that belongs to the group is terminated by the program it should disappear from the group’s children.

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 halts.

UC2.1 Auto expansion and selection on halted threads

• A thread belonging to a group or a recursive group is suspended due to a breakpoint ( or other).
  • 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.

• Have 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 containers are halted 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 levels)

• When a container is selected the Suspend command will be enabled if at least of 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 should 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 a container nodes ( processes, groups, threads) 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 a container 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 because 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 the top stack frame is selected when a debug session starts

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

Suported Use Cases:

1. The user selects multiple debug contexts in the Debug View and group them (via a context menu).

• A Group node will appear as parent of the selected containers.
  • A Group node will appear as parent of the selected containers.

2. After that the user will be able to perform debug commands over the group. 3. The command will be dispatched to all debug contexts in the group.

Additional concerns / options:

• The grouped containers may persist between debug sessions.
• Some grouping can be supported by the back end, or can be done with no knowledge of the back end.
• A debug container can belong to multiple groups.
• The user can rename the group.
• The back end can create initial groups.

Bug 336876 Grouping of Execution Elements for DSF debugger feature