An Extended Example
The g specifier can sometimes be confusing when is coupled with a group. In many cases, the reason that you use g is to force the group when the current default focus indicates another kind of focus. Stated in another way, isn't something like gL redundant?
The following example will clarify why and when you use the g specifier. The first step is to set a breakpoint in a multithreaded OMP program and execute the program until it hits the breakpoint:
d1.<> dbreak 35
Loaded OpenMP support library libguidedb_3_8.so :
KAP/Pro Toolset 3.8
1
d1.<> dcont
Thread 1.1 has appeared
Created process 1/37258, named "tx_omp_guide_llnl1"
Thread 1.1 has exited
Thread 1.1 has appeared
Thread 1.2 has appeared
Thread 1.3 has appeared
Thread 1.1 hit breakpoint 1 at line 35 in ".breakpoint_here"
The default focus is d1.<, which means that the CLI is at its default width, The process of interest is 1, and the thread of interest is the lowest numbered nonmanager thread. Because the default width for the dstatus command is "process", entering dstatus tells the CLI to display the status of all processes. Notice that typing dfocus p st produces the same output:
d1.<> dstatus
1: 37258 Breakpoint [tx_omp_guide_llnl1]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
1.2: 37258.2 Stopped PC=0xffffffffffffffff
1.3: 37258.3 Stopped PC=0xd042c944
d1.<> dfocus p dstatus
1: 37258 Breakpoint [tx_omp_guide_llnl1]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
1.2: 37258.2 Stopped PC=0xffffffffffffffff
1.3: 37258.3 Stopped PC=0xd042c944
Here's what the CLI displays when you ask for the status of the lockstep group. (The rest of this example will use the f abbreviation for dfocus.)
d1.<> f L dstatus
1: 37258 Breakpoint [tx_omp_guide_llnl1]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
This command tells the CLI to get the status of the threads in thread 1.1's (the thread of interest) lockstep group. The f L command modifier narrows the set so that the display only includes the threads in the process that are at the same PC as the thread of interest.
Note: By default, the dstatus command displays information at "process" width. This means that you do not need to type "f pL dstatus".
The next command runs thread 1.3 to the same line as thread 1.1. This is immediately followed by a command that displays the status of all the threads in the process:
d1.<> f t1.3 duntil 35
35@> write(*,*)"i= ",i,
"thread= ",omp_get_thread_num()
d1.<> f p dstatus
1: 37258 Breakpoint [tx_omp_guide_llnl1]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
1.2: 37258.2 Stopped PC=0xffffffffffffffff
1.3: 37258.3 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
As expected, the CLI has added a thread to the lockstep group:
d1.<> f L dstatus
1: 37258 Breakpoint [tx_omp_guide_llnl1]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
1.3: 37258.3 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
The next set of commands first narrows the width of the default focus to thread width--notice that the prompt changes--then displays the contents of the lockstep group.
d1.<> f t
t1.<> f L dstatus
1: 37258 Breakpoint [tx_omp_guide_llnl1]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
This is the hard step. While the lockstep group of the thread of interest has two threads, the current focus has only thread 1, and that thread is, of course, part of the lockstep group. Consequently, the lockstep group in the current focus is just the one thread.
If you ask for a wider width (p or g) with L, the CLI displays more threads from the lockstep group of thread 1.1.
t1.<> f pL dstatus
1: 37258 Breakpoint [tx_omp_guide_llnl1]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
1.3: 37258.3 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
t1.<> f gL dstatus
1: 37258 Breakpoint [tx_omp_guide_llnl1]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
1.3: 37258.3 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
t1.<>
Note: If the thread of interest is 1.1, "L" refers to group number 1.1, which is the lockstep group of thread 1.1.
Because this example only contains one process, the pL and gL modifiers produce the same result when used with dstatus. If, however, the program had additional processes in the group, you could only see them by using a gL modifier.
In this example, the focus indicated by the prompt--this focus is called the outer focus--controls the display. Notice what happens when dfocus commands are strung together:
t1.<> f d
d1.<
d1.<> f tL dstatus
1: 37258 Breakpoint [tx_omp_guide_llnl1]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
d1.<> f tL f p dstatus
1: 37258 Breakpoint [tx_omp_guide_llnl1]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
1.3: 37258.3 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
d1.<> f tL f p f D dstatus
1: 37258 Breakpoint [tx_omp_guide_llnl1]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
1.2: 37258.2 Stopped PC=0xffffffffffffffff
1.3: 37258.3 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
d1.<> f tL f p f D f L dstatus
1: 37258 Breakpoint [tx_omp_guide_llnl1]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
1.3: 37258.3 Breakpoint PC=0x1000acd0,
[./tx_omp_llnl1.f#35]
d1.<>
Stringing multiple focuses together may not produce the most readable result, and this example illustrates how one dfocus command can modify what another sees and will act upon. The ultimate result is an arena upon which a command will act. In these examples, the dfocus command is telling the dstatus command what it should be displaying.
