From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EY0LJSpM4mkl/R4AWB0awg (envelope-from ) for ; Fri, 17 Apr 2026 11:05:14 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=CynJe3CB; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 92EA91E0B1; Fri, 17 Apr 2026 11:05:14 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 06F4A1E093 for ; Fri, 17 Apr 2026 11:05:13 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id AA34F4AA396F for ; Fri, 17 Apr 2026 15:05:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AA34F4AA396F Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=CynJe3CB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 9F3094C91769 for ; Fri, 17 Apr 2026 14:54:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9F3094C91769 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9F3094C91769 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776437664; cv=none; b=A/f3mY0k/qyoL0lngf6/KImcnZ73DnWSsn3Nug2jBUl4EGbVIVEbdkHhrmUMSqVsaEDCjalx9cbhE2t3N+vrHGp5/1Rc51K++ljVAFXMLxWl4yVDDQNvHG2JN635IzoqAkB+O5g1Jskk/2I1gziLeipFoBcIJcmvjbOEn/iZ6pk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776437664; c=relaxed/simple; bh=PXrQ3oSEGMi/wzQQV4Q7uu1odbHdALOx8jEg0sKs6v8=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=GZ74seb5Q93cyc2aUMiAeFQfNCSMvaqbW+baMU/55hNPc/nLvKko2eyN9kUJLgD3uUbhfhw0VST926IMBS0Kp9Db1veKbJFXAPfqL01jK+UQjKlo696NYGPPUCzkxw8lQPNNumHck6bmW4Scarn+v1/BPTF304wzSUuIza7BqFA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9F3094C91769 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776437664; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q6jZJkAZb6UpUZvsvUkkVbpGkeYBtx8yEG9RrhiFa0k=; b=CynJe3CBUJarui4FSWtUWEsb6UhVzOaEWdavKYt26q1nirCMydLJcLS1VdetzWNwG+iVuc YMKmxDeEBx0iIGmplJ9DXGuDuqjy/3hC2bsLMELlfCPuwqz6uSfiLPcv3KSgNzoIuZ5qYw zlMScpGchpVdi+MF0Mxo3t7DAr8dP/4= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-686-niCjD2RXPDaXQocWvmwoew-1; Fri, 17 Apr 2026 10:54:16 -0400 X-MC-Unique: niCjD2RXPDaXQocWvmwoew-1 X-Mimecast-MFC-AGG-ID: niCjD2RXPDaXQocWvmwoew_1776437655 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-488c768a9a9so4921565e9.1 for ; Fri, 17 Apr 2026 07:54:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776437654; x=1777042454; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=q6jZJkAZb6UpUZvsvUkkVbpGkeYBtx8yEG9RrhiFa0k=; b=RmH5Wu6NVy3gpNes22UuZe55sBFhUKlXKynxD0TobD8XU/x8pAh1Hy3IqAtw5wWSEK XMsm+y9MmaRoN/+2jwxPVT08K3fXb+eogOcu+roLnLRCoWokmib5b8OvNfU7SoxXMZzP hzxzPWlrYmzEYBS2yH0HaT0o3/Zvk0HchoFTLt9wNR0JWwPQ/NPl6Ev8Dm7gEgk0WV1H V4RkG5cyj62jWdVFGNcS7wVCx2ffqU32ux59qzjabaGzQzOgD0dU+vPnfte8r8fIXh+J QZReoRQhxqK9KUFsc2WXbH6mc4on9/BvJ9MI0R8n88p2XGUxl/C91XFR6DVPG8oEWmPH VDrw== X-Gm-Message-State: AOJu0YwkBz3FK7rWtdoF/RczE67pCBshVIh5DzNI7gJdPlbJTWVqSJay Ulrz2v6Uax1aIO7/VcdEsKwDOU4jkUyW3vdj7o4rkNBvHu4nucD7MLjrHykccLvL++z7Af04Cl4 thNddwQ8Rejgi1QOsCBskkLIQFP3wXqim66Bix3SI9PFZkQgJIo5/7AjLrveYDnXaD0rDyjjv+p Q0NC6OdDTHcZAp8Mdoz7iGhTyIM3qUN24dobGLq0IpsyTl98o= X-Gm-Gg: AeBDievi3qksWKvcAQZdzc/fZTj9U6+kSZitpVocmr5RYqYpEn1Td3P3qiUFCCpP/IO 0CM8qrhFjOz897IvvjvXH2dk+5zY2jCCvw3Ob3NzeCUJiVVmIG/OhAp8F4wmM8r8REUgl48feNr l9DJkj9+oYQnlWaIw1d61ZWT7tzU7p+KCrMpHJS/jPaGKWPHtehvMT2RtgkQaD441Veln1B69lk RBUTCjAGwo/45Un+PdNfF0T5ZIMdSgF9uTfB2lkSfmrIsMnsECydyUfEFlPhfzDVJ0fsFArUrhS ZgvLxYQ84AVtVUx5TzsdG6AXDYb4HkUGXvKEKxLNP43FjbMi8ApmvjvXk6wuPGigHl9BDhh6TrX QVGkNQoVNu+gI15iBtcyskAwEsR8= X-Received: by 2002:a05:600c:3e05:b0:486:ffa3:594 with SMTP id 5b1f17b1804b1-488fb78049amr49721075e9.23.1776437654052; Fri, 17 Apr 2026 07:54:14 -0700 (PDT) X-Received: by 2002:a05:600c:3e05:b0:486:ffa3:594 with SMTP id 5b1f17b1804b1-488fb78049amr49720275e9.23.1776437653251; Fri, 17 Apr 2026 07:54:13 -0700 (PDT) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488fb75ab25sm19047405e9.11.2026.04.17.07.54.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Apr 2026 07:54:12 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess , Guinevere Larsen Subject: [PATCHv3] gdb: notify of inferior switch when needed from 'thread' command Date: Fri, 17 Apr 2026 15:54:11 +0100 Message-Id: <3c8d246a5262fbb39a0f352498e1a2592061f478.1776437170.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: <106ee09a80eac0dcc72d134dbf02f567de7163ce.1769435821.git.aburgess@redhat.com> References: <106ee09a80eac0dcc72d134dbf02f567de7163ce.1769435821.git.aburgess@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: rxCZjopqoFQBQ5AF8_gXdDDOxcykEGSFBwA3p-yihhM_1776437655 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org I looked into the issues that Baris raised in this email: https://inbox.sourceware.org/gdb-patches/IA0PR11MB7307BB4B5B3CC3A354289261C4C7A@IA0PR11MB7307.namprd11.prod.outlook.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 --- gdb/mi/mi-main.c | 49 ++++++++++++---- .../gdb.mi/user-selected-context-sync.exp | 56 ++++++++++++++++--- .../gdb.python/py-selected-context.exp | 19 +++++++ gdb/thread.c | 13 ++++- 4 files changed, 115 insertions(+), 22 deletions(-) diff --git a/gdb/mi/mi-main.c b/gdb/mi/mi-main.c index bf08fe822b3..47b9be3e54a 100644 --- a/gdb/mi/mi-main.c +++ b/gdb/mi/mi-main.c @@ -538,6 +538,11 @@ mi_cmd_thread_select (const char *command, const char *const *argv, int argc) thread_select (argv[0], thr); + /* We don't call print_selected_inferior here as this never prints + anything when the output is MI like (as it is now). MI consumers are + expected to derive the inferior change from the global thread-id + included in the print_selected_thread_frame output. */ + print_selected_thread_frame (current_uiout, USER_SELECTED_THREAD | USER_SELECTED_FRAME); } @@ -1968,14 +1973,33 @@ struct user_selected_context save_selected_frame (&m_previous_frame_id, &m_previous_frame_level); } - /* Return true if the user selected context has changed since this object - was created. */ - bool has_changed () const + /* Return a set of flags indicating which parts of the user selected + context has changed since this object was created, or 0 (the empty + set of flags) if nothing has changed. */ + user_selected_what what_changed () const { + /* If anything changed then we report both the thread and frame at a + minimum. We optionally add the inferior if we know that it + changed. + + This means that for pure frame changes, e.g. -stack-select-frame, we + still report both a thread and a frame, which isn't ideal, but + there's also the cases where -thread-select is used to re-select the + current thread, in this case we'd still like to see the thread + reported, at least, that's what we have historically done. */ + user_selected_what state + = USER_SELECTED_THREAD | USER_SELECTED_FRAME; + /* Did the selected thread change? */ if (m_previous_ptid != null_ptid && inferior_ptid != null_ptid && m_previous_ptid != inferior_ptid) - return true; + { + /* Did the inferior change too? */ + if (m_previous_ptid.pid () != inferior_ptid.pid ()) + state |= USER_SELECTED_INFERIOR; + + return state; + } /* Grab details of the currently selected frame, for comparison. */ frame_id current_frame_id; @@ -1984,7 +2008,7 @@ struct user_selected_context /* Did the selected frame level change? */ if (current_frame_level != m_previous_frame_level) - return true; + return state; /* Did the selected frame id change? If the innermost frame is selected then the level will be -1, and the frame-id will be @@ -1993,10 +2017,10 @@ struct user_selected_context other than the innermost frame selected. */ if (current_frame_level != -1 && current_frame_id != m_previous_frame_id) - return true; + return state; /* Nothing changed! */ - return false; + return 0; } private: /* The previously selected thread. This might be null_ptid if there was @@ -2100,10 +2124,13 @@ mi_cmd_execute (struct mi_parse *parse) parse->cmd->invoke (parse); - if (!parse->cmd->preserve_user_selected_context () - && current_user_selected_context.has_changed ()) - interps_notify_user_selected_context_changed - (USER_SELECTED_THREAD | USER_SELECTED_FRAME); + if (!parse->cmd->preserve_user_selected_context ()) + { + user_selected_what what + = current_user_selected_context.what_changed (); + if (what != 0) + notify_user_selected_context_changed (what); + } } /* See mi-main.h. */ diff --git a/gdb/testsuite/gdb.mi/user-selected-context-sync.exp b/gdb/testsuite/gdb.mi/user-selected-context-sync.exp index 844206f7511..fb781205a20 100644 --- a/gdb/testsuite/gdb.mi/user-selected-context-sync.exp +++ b/gdb/testsuite/gdb.mi/user-selected-context-sync.exp @@ -698,9 +698,21 @@ proc_with_prefix test_cli_thread { mode } { } } - # 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. + with_test_prefix "thread 2.2" { + # Select a thread in a different inferior. This should trigger an + # 'inferior changed' and 'thread changed' notification on the CLI, + # and a single MI async notification. + set mi_re [make_mi_re $mode 5 0 event] + set cli_re [make_cli_re $mode 2 2.2 0] + + with_spawn_id $gdb_main_spawn_id { + gdb_test "thread 2.2" $cli_re "select thread" + } + + with_spawn_id $mi_spawn_id { + match_re_or_ensure_no_output $mi_re "select thread, event on MI" + } + } } # Test frame selection from CLI. @@ -995,9 +1007,22 @@ proc_with_prefix test_mi_thread_select { mode } { } } - # 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. + with_test_prefix "thread 2.2" { + # Select a thread in a different inferior. This should trigger an + # 'inferior changed' and 'thread changed' notification on the CLI, + # and a single MI async notification. + set mi_re [make_mi_re $mode 5 0 response] + set cli_re [make_cli_re $mode 2 2.2 0] + + with_spawn_id $mi_spawn_id { + mi_gdb_test "-thread-select 5" $mi_re "-thread-select" + } + + with_spawn_id $gdb_main_spawn_id { + match_re_or_ensure_no_output "$cli_re\r\n" "-thread-select, event on CLI" + } + + } } proc_with_prefix test_mi_stack_select_frame { mode } { @@ -1290,9 +1315,22 @@ proc_with_prefix test_cli_in_mi_thread { mode cli_in_mi_mode } { } } - # 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. + with_test_prefix "thread 2.2" { + # Select a thread in a different inferior. This should trigger an + # 'inferior changed' and 'thread changed' notification on the CLI, + # and a single MI async notification. + set command [make_cli_in_mi_command $cli_in_mi_mode "thread 2.2"] + set mi_re [make_cli_in_mi_re $command $cli_in_mi_mode $mode 1 2 2.2 5 0] + set cli_re [make_cli_re $mode 2 2.2 0] + + with_spawn_id $mi_spawn_id { + mi_gdb_test $command $mi_re "select thread" + } + + with_spawn_id $gdb_main_spawn_id { + match_re_or_ensure_no_output "$cli_re\r\n" "select thread, event on CLI" + } + } } # Test selecting the frame using a CLI command in the MI channel. diff --git a/gdb/testsuite/gdb.python/py-selected-context.exp b/gdb/testsuite/gdb.python/py-selected-context.exp index 030543466d2..28b9b456003 100644 --- a/gdb/testsuite/gdb.python/py-selected-context.exp +++ b/gdb/testsuite/gdb.python/py-selected-context.exp @@ -129,3 +129,22 @@ gdb_test "down" [event_regexp 1 1.2 #0] \ "move down a frame, event handler triggers" gdb_test "frame 1" [event_regexp 1 1.2 #1] \ "select a frame, event handler triggers" + +# Check that switching threads via MI also triggers the Python +# selected_context event. Grab the regexp we expect for the CLI, pull +# it apart, and wrap each line with the usual ~"...\n" wrapper we see +# with MI. Then add the MI '^done,....' line, and make this into +# the expected output regexp. +set cli_pattern [event_regexp 1 1.1 #0] +set cli_pattern [string map {\r\n \n} $cli_pattern] +set cli_pattern [split $cli_pattern \n] +set mi_pattern {} +foreach line $cli_pattern { + lappend mi_pattern "~\"$line\\\\n\"" +} +lappend mi_pattern "\\^done,new-thread-id=\"1\",\[^\r\n\]+" +set pattern [multi_line {*}$mi_pattern] + +# Switch threads using the MI. Python event should trigger. +gdb_test "interpreter-exec mi \"-thread-select 1\"" $pattern \ + "mi thread switch triggers Python event" diff --git a/gdb/thread.c b/gdb/thread.c index a6ae2a75139..46170537e28 100644 --- a/gdb/thread.c +++ b/gdb/thread.c @@ -2010,10 +2010,19 @@ thread_command (const char *tidstr, int from_tty) } else { + inferior *previous_inferior = current_inferior (); + thread_select (tidstr, parse_thread_id (tidstr, NULL)); - notify_user_selected_context_changed - (USER_SELECTED_THREAD | USER_SELECTED_FRAME); + user_selected_what selection = (USER_SELECTED_THREAD + | USER_SELECTED_FRAME); + + /* If the inferior changed as a consequence of the thread change, + then let the user know. */ + if (previous_inferior != current_inferior ()) + selection |= USER_SELECTED_INFERIOR; + + notify_user_selected_context_changed (selection); } } base-commit: cc4600477f621c764011b8e2f5bf1a2ebcffb61a -- 2.25.4