Focus control

The focus control allows you to focus on individual processes, or threads, or on process groups. When focused on a particular process or thread, actions such as stepping, playing/pausing, or adding breakpoints, will only apply to that process or thread rather than the entire group.

Focusing affects a number of different controls in the main window. The user interface will change depending on whether you are focused on group, process, or thread. The relevant information about your currently focused object will be displayed.

Note

Focus control does not affect all windows. Windows such as the Multi-Dimensional Array Viewer, Memory Debugger, and Cross-Process Comparison are unchanged.

Process group viewer

The changes to the process group viewer are the most obvious in the user interface when using focus control. When focus on current group is selected, you see your process groups. If you switch to focus on current process or thread, the view changes to show the processes in the currently selected group, with their corresponding threads.

The Process Group Detailed View focused on a process

If there are 32 threads or more, by default the threads will be displayed using a Summary view (as in the Process Group View). You can change the view mode using the context menu.

If focused on process, a tooltip shows the OpenMP thread ID of each thread, if the value exists.

Breakpoints tab

The Breakpoints tab is filtered to only display breakpoints relevant to your current group, process, or thread. When focused on a process, the Breakpoints tab displays which thread the breakpoint belongs to. If you are focused on a group, the tab displays both the process and the thread the breakpoint belongs to.

Source Code viewer

The line highlight color in the Source Code viewer shows you a stack back trace of where each thread is in the call stack. This is filtered by the currently focused item, for example when focused on a particular process, you only see the back trace for the threads in that process.

Also, when you add breakpoints using the Source Code viewer, they are added for the group, process, or thread that is currently focused.

Parallel Stack View

The Parallel Stack View can also be filtered by focusing on a particular process group, process, or thread.

Playing and stepping

The behavior of playing, stepping, and the Run to here feature are also affected by your currently focused item:

When focused on process group, the entire group is affected
When focused on thread, only the current thread is executed
When focused on process, only the current process is executed. In this case you can also use the Step threads together feature.

Step threads together

The Step threads together feature is only available when focused on process. If this option is enabled, the threads in the current process are synchronized when performing actions such as stepping, pausing, and using Run to here.

For example, if you have a process with two threads and you choose Run to here, your program will be paused when either of the threads reaches the specified line. If Step threads together is selected, both of the threads will be played to the specified line before the program is paused.

Note

You should always use Step threads together and Run to here to enter or move within OpenMP parallel regions. With many compilers it is also advisable to use Step threads together when leaving a parallel region, because threads can get “left behind” inside system-specific locking libraries and may not enter the next parallel region on the first attempt.

When using the Step threads together feature it is not always possible for all threads to synchronize at their target. There are two main reasons for this:

One or more threads may branch into a different section of code (and never reach the target). This is especially common in OpenMP codes, where worker threads are created and remain in holding functions during sequential regions.
As most of the supported debug interfaces cannot play arbitrary groups of threads together, this behavior is simulated by playing each thread in turn. This is usually not a problem, but can be if, for example, thread 1 is playing, but waiting for thread 2 (which is not currently playing). Arm DDT attempts to resolve this automatically but cannot always do so.

If either of these conditions occur, the Stepping threads window opens, displaying the threads which have not yet reached their target.

The Stepping threads window also displays the status of threads, which may be one of the following:

Done: The thread has reached it target (and has been paused).
Skipped: The thread has been skipped and paused. Arm DDT no longer waits for it to reach its target.
Playing: This is the thread that is currently being executed. Only one thread may be playing at a time while the Stepping threads window is open.
Waiting: The thread is currently awaiting execution. When the currently playing thread is done or has been skipped, the highest waiting thread in the list is executed.

The Stepping threads window also lets you interact with the threads with the following options:

Skip: Arm DDT skips and pauses the currently playing thread. If this is the last waiting thread the window is closed.
Try Later: The currently playing thread is paused, and added to the bottom of the list of threads to be retried later. This is useful if you have threads which are waiting on each other.
Skip All: This skips, and pauses, all of the threads and closes the window.