Re: [PATCH] gdb: notify of inferior switch when needed from 'thread' command

[Pedro Alves <pedro@palves.net>]

Hi!

On 2025-10-08 09:48, Andrew Burgess wrote:

> What this message is talking about is this behaviour:
> 
>   (gdb) info threads
>     Id   Target Id                              Frame
>     1.1  Thread 0xf7dbc700 (LWP 818430) "thr" 0xf7eb2888 in clone () from /lib/libc.so.6
>     1.2  Thread 0xf7dbbb40 (LWP 818433) "thr" 0xf7fd0579 in __kernel_vsyscall ()
>     1.3  Thread 0xf73ffb40 (LWP 818434) "thr" breakpt () at thr.c:19
>     2.1  Thread 0xf7dbc700 (LWP 818456) "thr" 0xf7eb2888 in clone () from /lib/libc.so.6
>     2.2  Thread 0xf7dbbb40 (LWP 818457) "thr" breakpt () at thr.c:19
>   * 2.3  Thread 0xf73ffb40 (LWP 818458) "thr" breakpt () at thr.c:19
>   (gdb) inferior 1
>   [Switching to inferior 1 [process 818430] (/home/andrew/tmp/thr)]
>   [Switching to thread 1.1 (Thread 0xf7dbc700 (LWP 818430))]
>   #0  0xf7eb2888 in clone () from /lib/libc.so.6
>   (gdb) thread 2.2
>   [Switching to thread 2.2 (Thread 0xf7dbbb40 (LWP 818457))]
>   #0  breakpt () at thr.c:19
>   19	  while (stop)
>   (gdb)
> 
> Notice that when we switch from thread 2.3 to 1.1 using the 'inferior
> 1' command, GDB tells us that the inferior has changed, and that the
> thread has changed (and also that the frame has changed).
> 
> But, when we switch from 1.1 to 2.2 using the 'thread 2.2' command, we
> are only told about the thread change.
> 
> The 'Switching to inferior ...' line includes some useful information,
> the process PID and the executable name, and I think it is a shame
> that these are not presented when using the 'thread' command to switch
> inferior.

AMD and Intel have been having discussions about settling on how to 
expose GPU lane debugging in GDB for the past year, and this very detail
came up there.

(There was a presentation/BoF about the topic at the Cauldron and videos/slides
are already up:
https://conf.gnu-tools-cauldron.org/opo25/talk/FN7FKL/ )

For lane debugging support, we're going to propose a new "lane" command (along with
'info lanes', 'lane find', 'break foo lane N' etc.), where "lane" is new level of
execution context.  Currently an inferior has threads.  And with lane debugging, 
a thread has lanes.  So inferior has threads, thread has lanes.  A lane has
a fully-qualified ID like "I.T.L" (inferior.thread.lane), just like threads have a
fully qualified ID like "I.T".

For the issue at hand, it works like this:

 (gdb) inferior 1
 [Switching to inferior 1 [process 3286570] (/home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.rocm/simple/simple)]
 [Switching to thread 1.7 (AMDGPU Wave 1:2:1:1 (0,0,0)/0)]
 [Switching to lane 1.7.0 (AMDGPU Lane 1:2:1:1/0 (0,0,0)[0,0,0])]
 #0  do_an_addition (a=1, b=2, out=0x7ffee3e00000) at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.cpp:24
 24        *out = a + b;
 (gdb) thread 7
 [Switching to thread 1.7 (AMDGPU Wave 1:2:1:1 (0,0,0)/0)]
 [Switching to lane 1.7.0 (AMDGPU Lane 1:2:1:1/0 (0,0,0)[0,0,0])]
 #0  do_an_addition (a=1, b=2, out=0x7ffee3e00000) at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.cpp:24
 24        *out = a + b;
 (gdb) lane 0
 [Switching to lane 1.7.0 (AMDGPU Lane 1:2:1:1/0 (0,0,0)[0,0,0])]
 #0  do_an_addition (a=1, b=2, out=0x7ffee3e00000) at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.cpp:24
 24        *out = a + b;


Note this is just reusing the logic of the current behavior you observed
with "inferior" and "thread".

There is a logic/pattern to it that I think is the right balance.

Let me explain.

When you do "inferior 1", GDB also switches to some thread of inferior 1.
Reusing your example, if GDB didn't print about what thread it switched
to, and just said:

 (gdb) inferior 1
 [Switching to inferior 1 [process 818430] (/home/andrew/tmp/thr)]
 #0  0xf7eb2888 in clone () from /lib/libc.so.6

then the user would have no way to know what thread is now current,
and would be forced to issue the "thread" command to get it.  So
that's why current GDB prints the "Switch to thread" part too:

 (gdb) inferior 1
 [Switching to inferior 1 [process 818430] (/home/andrew/tmp/thr)]
 [Switching to thread 1.1 (Thread 0xf7dbc700 (LWP 818430))]
 #0  0xf7eb2888 in clone () from /lib/libc.so.6

This however, does not apply when you use the "thread" command instead
of the "inferior" command, as in, you are not _forced_ to use the
"inferior" command.  That is because in that case, the
"Switching to thread 2.2" part, as in your example:

 (gdb) thread 2.2
 [Switching to thread 2.2 (Thread 0xf7dbbb40 (LWP 818457))]
  #0  breakpt () at thr.c:19
  19	  while (stop)

... that "thread 2.2" part already tells you which inferior it is
GDB switched to.  It's inferior 2, from "2.2", which is "I.T".

That is why in my example above, when I switch to lane 0 with the
"lane" command, GDB only needs to tell me about the lane switch and
not the "inferior" and "thread" switching:

 (gdb) lane 0
 [Switching to lane 1.7.0 (AMDGPU Lane 1:2:1:1/0 (0,0,0)[0,0,0])]
 #0  do_an_addition (a=1, b=2, out=0x7ffee3e00000) at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.cpp:24
 24        *out = a + b;

From "lane 1.7.0", I already know the inferior (1) and the thread (7), so
GDB doesn't need to say it.  I _can_ use the "inferior" and "thread"
commands to get more information if I want, but I'm not _forced_ to.

So the current logic, extended to lanes, is I think simple -- when you
switch to an execution object using a "FOO" command, then GDB informs
you about the current FOO it switched to, as well as any finer
execution object context below FOO.  I.e., 

 - if you use the "inferior" command, GDB tells you about
   "inferior", "thread" and "lane" (if lanes exist).

 - if you use the "thread" command, GDB tells you about
   "thread" and "lane" (if lanes exist).

 - if you use the "lane" command, GDB tells you about
   "lane".

This reduces noise for a set of core commands that are used all the time.
When you're focused on switching threads around to debug something, you don't
need to be told what is the current program the inferior is running.
IMHO, it ends up being noise after a short while, like:

 (gdb) lane 0
 [Switching to inferior 1 [process 3286570] (/home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.rocm/simple/simple)]
 [Switching to thread 1.7 (AMDGPU Wave 1:2:1:1 (0,0,0)/0)]
 [Switching to lane 1.7.0 (AMDGPU Lane 1:2:1:1/0 (0,0,0)[0,0,0])]
 #0  do_an_addition (a=1, b=2, out=0x7ffee3e00000) at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.cpp:24
 24        *out = a + b;

 (gdb) lane 1
 [Switching to inferior 1 [process 3286570] (/home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.rocm/simple/simple)]
 [Switching to thread 1.7 (AMDGPU Wave 1:2:1:1 (0,0,0)/0)]
 [Switching to lane 1.7.1 (AMDGPU Lane 1:2:1:1/1 (0,0,0)[0,0,1])]
 #0  do_an_addition (a=<lane inactive>, b=<lane inactive>, out=<lane inactive>)
     at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.cpp:24
 24        *out = a + b;

etc., etc.


IOW, even though you could argue that the "Switching to inferior ..."
information could be useful when you use the "thread" command, that is
information that the user can easily retrieve with the "inferior"
command.  I think reducing noise is more important here, especially when
we start adding other levels of execution objects, like lanes.

(If you happen to have an AMD GPU, you can play with my examples above
using this branch:
  https://github.com/ROCm/ROCgdb/tree/users/palves/lane-debugging)

Pedro Alves