RE: [PATCHv3] gdb: notify of inferior switch when needed from 'thread' command

["Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>]

On Friday, April 17, 2026 4:54 PM, Andrew Burgess wrote:
> I looked into the issues that Baris raised in this email:
> 
>   https://inbox.sourceware.org/gdb-
> patches/IA0PR11MB7307BB4B5B3CC3A354289261C4C7A@IA0PR11MB7307.namprd11.prod.outloo
> k.com
> 
> About how in a multi-inferior debug session, if hitting a breakpoint
> triggers a thread AND inferior switch, then we announce the new
> thread, but not the new inferior.  This is very similar to the fix
> being proposed in this patch.
> 
> However, in this case we don't use
> notify_user_selected_context_changed to announce the new
> thread/inferior, instead this is done in normal_stop (infrunc.c).
> 
> I think we could and should change this code to announce the inferior
> switch where appropriate.  But given this change would be quite
> different to the changes in this patch, then my current plan is to do
> that in a follow up change once this is merged.
> 
> Speaking of which, my current plan is to push this next week.  I don't
> think Pedro, who had feedback on V1, is actively reviewing patches any
> more, but if there's any feedback post-commit, I'm happy to discuss
> things then.
> 
> In v3:
> 
>   - Rebased and retested.
> 
> In v2:
> 
>   - Rebased and retested.
> 
>   - Reworked commit message to try and address Pedro's concerns.
> 
> Thanks,
> Andrew
> 
> ---
> 
> While working on the commit:
> 
>   commit 9959019545d8d6d71d927f20f088efba944b1e9c
>   Date:   Sun Sep 28 16:16:53 2025 +0100
> 
>       gdb: fix for 'set suppress-cli-notifications on' missed case
> 
> I spotted this message in the gdb.mi/user-selected-context-sync.exp
> test script:
> 
>   # Idea for the future: selecting a thread in a different inferior.  For now,
>   # GDB doesn't show an inferior switch, but if it did, it would be a nice
>   # place to test it.
> 
> 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.
> 
> So, this commit addresses this issue.
> 
> A question that came up during review, and which I'm clarifying here:
> this change only affects the output of GDB when the thread command is
> also used to switch inferiors.  I am (in effect) arguing that the
> command 'thread 2.2' should be treated as a shorthand for 'inferior 2;
> thread 2', and should display all of the associated output.  If the
> user is only switching threads within a single inferior then it is not
> necessary to re-display the inferior information.
> 
> I acknowledge that this does mean the output of the 'thread' command
> will now be different depending on whether the user changes inferior
> or not.  However, I think this is better than the alternative, having
> the 'thread' command always re-print the inferior information.  I
> think this would introduce excess noise that is not useful.
> 
> There are changes in basically two areas.  The easy part is in
> thread_command (thread.c).  Here we spot when the inferior has changed
> as a result of the 'thread' command, and include
> USER_SELECTED_INFERIOR in the set of state passed to the
> notify_user_selected_context_changed function.
> 
> The change in mi/mi-main.c is a little more involved.  In the
> mi_cmd_execute function we use an instance of user_selected_context to
> spot if any inferior state (frame, thread, or inferior) changes after
> an MI command, this is then used to decide if there should be a call
> to interps_notify_user_selected_context_changed.
> 
> First, by calling interps_notify_user_selected_context_changed
> directly, instead of notify_user_selected_context_changed, we fail to
> trigger the Python selected_context event, which feels like a
> mistake.  If the context is changed via an MI command, I think we
> should still trigger the Python event.  So the first thing I did was
> change the interps_notify_user_selected_context_changed call into a
> call to notify_user_selected_context_changed.  I updated the
> gdb.python/py-selected-context.exp test to cover this case.
> 
> After that, in mi_cmd_execute, notify_user_selected_context_changed is
> always passed 'USER_SELECTED_THREAD | USER_SELECTED_FRAME'.  This
> makes sense, the MI doesn't allow "switching inferiors" as a command,
> instead, an MI frontend must switch threads, and the inferior is
> switched as a consequence.  But this does mean that if a user has a
> CLI and MI interpreter running, and the MI switches threads, the CLI
> will only receive the thread switch style notifications, that is,
> there will be no "Switching to inferior ..." line.
> 
> What I've done is rename user_selected_context::has_changed to
> user_selected_context::what_changed, this function is now responsible
> for returning the set of USER_SELECTED_* flags that indicate what
> changed.
> 
> If anything has changed then we always return USER_SELECTED_THREAD |
> USER_SELECTED_FRAME as a minimum.  This retains the existing
> behaviour, but is possibly more aggressive than we need to be; the
> -stack-select-frame command can only change the frame, so maybe in
> this case we should only return USER_SELECTED_FRAME?  I've left that
> for the future though.
> 
> However, the important change is that in ::what_changed, I now spot
> when the inferior has changed and include USER_SELECTED_INFERIOR in
> the set of flags that are returned.
> 
> In mi_cmd_execute we now call the new what_changed function, and use
> the set of flags returned when calling
> notify_user_selected_context_changed.  This means that the CLI will
> now receive inferior changed notifications when appropriate.
> 
> The gdb.mi/user-selected-context-sync.exp script has been updated,
> replacing the comment I quoted above with an actual test that the
> inferior change is announced correctly.
> 
> Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

I looked at the patch, ran the testsuite, and did some manual runs.

Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

Thanks
-Baris

Intel Deutschland GmbH
Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928