The meaning of the g width specifier is sometimes not clear when it is coupled with a group scope specifier. Why have a g specifier when you have four other group specifiers? Stated in another way, isn’t something like gL redundant?
The simplest answer, and the reason you most often use the g specifier, is that it forces the group when the default focus indicates something different from what you want it to be.
The following example shows this. The first step sets a breakpoint in a multi-threaded OMP program and executes the program until it hits the breakpoint.
d1.<> dbreak35
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 "omp_prog"
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 POI is 1, and the TOI is the lowest numbered nonmanager thread. Because the default width for the dstatus command is process, the CLI displays the status of all processes. Typing dfocus p dstatus produces the same output.
d1.<> dstatus
1: 37258 Breakpoint [omp_prog]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./omp_prog.f#35]
1.2: 37258.2 Stopped PC=0xffffffffffffffff
1.3: 37258.3 Stopped PC=0xd042c944
d1.<> dfocus p dstatus
1: 37258 Breakpoint [omp_prog]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./omp_prog.f#35]
1.2: 37258.2 Stopped PC=0xffffffffffffffff
1.3: 37258.3 Stopped PC=0xd042c944
The CLI displays the following when you ask for the status of the lockstep group. (The rest of this example uses the f abbreviation for dfocus, and st for dstatus.)
d1.<> f L st
1: 37258 Breakpoint [omp_prog]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./omp_prog.f#35]
This command tells the CLI to display the status of the threads in thread, which is the 1.1 lockstep group since this thread is the TOI. The f L focus command narrows the set so that the display only includes the threads in the process that are at the same PC as the TOI.
NOTE >> By default, the dstatus command displays information at process width. This means that you don’t need to type f pL dstatus.
The duntil command runs thread 1.3 to the same line as thread 1.1. The dstatus command then displays the status of all the threads in the process:
d1.<> f t1.3duntil35
35@> write(*,*)"i= ",i,
"thread= ",omp_get_thread_num()
d1.<> f p dstatus
1: 37258 Breakpoint [omp_prog]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./omp_prog.f#35]
1.2: 37258.2 Stopped PC=0xffffffffffffffff
1.3: 37258.3 Breakpoint PC=0x1000acd0,
[./omp_prog.f#35]
As expected, the CLI adds a thread to the lockstep group:
d1.<> f L dstatus
1: 37258 Breakpoint [omp_prog]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./omp_prog.f#35]
1.3: 37258.3 Breakpoint PC=0x1000acd0,
[./omp_prog.f#35]
The next set of commands begins by narrowing the width of the default focus to thread width—notice that the prompt changes—and then displays the contents of the lockstep group:
d1.<> f t
t1.<> f L dstatus
1: 37258 Breakpoint [omp_prog]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./omp_prog.f#35]
Although the lockstep group of the TOI has two threads, the current focus has only one thread, and that thread is, of course, part of the lockstep group. Consequently, the lockstep group in the current focus is just the one thread, even though this thread’s lockstep group has two threads.
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. as follows:
t1.<> f pL dstatus
1: 37258 Breakpoint [omp_prog]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./omp_prog.f#35]
1.3: 37258.3 Breakpoint PC=0x1000acd0,
[./omp_prog.f#35]
t1.<> f gL dstatus
1: 37258 Breakpoint [omp_prog]
1.1: 37258.1 Breakpoint PC=0x1000acd0,
[./omp_prog.f#35]
1.3: 37258.3 Breakpoint PC=0x1000acd0,
[./omp_prog.f#35]
NOTE >> If the TOI 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 specifiers produce the same result when used with the dstatus command. If, however, there were additional processes in the group, you only see them when you use the gL specifier.