From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id k30iBn2uuWnW2y0AWB0awg (envelope-from ) for ; Tue, 17 Mar 2026 15:41:49 -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=CGcTX8Dm; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 043271E08C; Tue, 17 Mar 2026 15:41:48 -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 B2A981E08C for ; Tue, 17 Mar 2026 15:41:47 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 2B6F44BB58C7 for ; Tue, 17 Mar 2026 19:41:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2B6F44BB58C7 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=CGcTX8Dm Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 802794BB5924 for ; Tue, 17 Mar 2026 19:41:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 802794BB5924 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 802794BB5924 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773776478; cv=none; b=iC4KhGYwwaumvc9DaC1t/DMoSnmnK/zcFD6wa0jGEroSHCOCB9eAUOnBTliuAiNbbUNqtPALIXHzJ/kFeXOBnoXYoeFvCCDTyRdWI/nASAZUVKcztHg9pGBz0y09RSgLdjj5gJX316yk9WAQxOM01b2x2T4LlW3817ZLj2tNDYo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773776478; c=relaxed/simple; bh=ZSjiMFyBvtFNo3/VCUp0J3YgK8u7ClcykRxChRBNDd8=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=aPa8bVutLqB9HCnhRdqQPp5qyz793Cg35YgBRvVhbgg0sk6yEaMenidreZ62rwayW47TDtbV4z6Cq5rSoDQeCGK+v11n6zAnVxJmHwJxLpH/lU4baAeQJL8UmcC6+kwSX4bjLA0NgWr9sPTl5AE13CJ1/jeMeY4aMJHj7RlcCCY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 802794BB5924 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773776478; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pKJkczoZiuxuDD2Oo50zLhPAC5cbOL6X0lBQdKkud1k=; b=CGcTX8DmZILgjaG9y98IwVtCZn1aTbsH7UGYcDIpexBvEAr1HDRAX/x2IkwXZlLoVeUiox qyw8J1xwygimx6pT4YxUhwDp784GnmMASeScj7I+ynKij9CLXcNnGTzc2d3VZlwv2P6GFg RKoT47idclVDWqztp5d2bgJeVhpJTO8= Received: from mail-dy1-f198.google.com (mail-dy1-f198.google.com [74.125.82.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-207-qyNAjT9ON62yIi8-dAng8w-1; Tue, 17 Mar 2026 15:41:16 -0400 X-MC-Unique: qyNAjT9ON62yIi8-dAng8w-1 X-Mimecast-MFC-AGG-ID: qyNAjT9ON62yIi8-dAng8w_1773776475 Received: by mail-dy1-f198.google.com with SMTP id 5a478bee46e88-2be9eb18804so40196eec.1 for ; Tue, 17 Mar 2026 12:41:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773776474; x=1774381274; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pKJkczoZiuxuDD2Oo50zLhPAC5cbOL6X0lBQdKkud1k=; b=jSvfNt2SBGO9g1W7brUymtIztoCAT/SuldxJyOp9aWc9KihFqSTHeXfb9YoY+aNl7x GQ4DKga3SzRqIBIReTEC8PYJrrZm2xIsRHqqV7dIUI98CooqH2BNBziRAAO7ogzzp4M3 nzi6bCLUIYNQBjT6xKkJzHC9uAlGvXkUUerpUCwbi4hNkZYkfLSRFp161n9XYxnzGsbG y9AtOxnZDSDinU+K8ZvIEIZ2FMAzH7RLK05SsprDMuLmQWpmxndKs8bXUseE5fE4WBYN aPhz2W6RmBV1s2Dyc8IIiTVpL3joYAOQ9yDUB3F9QPo8XeoflnubgtJ14R3YBYoT8Uco p8Ig== X-Forwarded-Encrypted: i=1; AJvYcCWxy7Ecwyl4oFA9fakSD7D6E3owJM2vjbLg4LA1iy2KxhZhqtnepgzwsPxEASQg4MVH9XSLLrNcZKLXLg==@sourceware.org X-Gm-Message-State: AOJu0Yz8nihTJKYPZ6nGe9ni5XP5dYlQIHzP0ZFc//mUzqtq57MNTOHt Z9UgKnlEGrhjSkeLiilwmAjk7PmiCZWIRd+15CseLI4Y6JPFr2SUbz/Nw/mxaYD3CN43p+mId5S t2MJ5pCmQqDIy3g+4ngcjQkpybbhDBSsteiDgirjENcouB0RnHaqDWb6+lICPhBJVDw104S8= X-Gm-Gg: ATEYQzwyYsMf/Of1kWXtFEB8kf+dj3fYgFh/ZZ2GkZCRKcIA37HrY+HgO4+4g9ObFNf nsEl4lBFYTgNlquM7QzYiEezY9FtojcOxt5p9GwN4OZT43GTwgWCyLlMfTynbwY/gIGgEqE/uAa NHZXFS8piSsf+UXrxXFrytQqrrKpP8VkaAHHLKAYns6zkBe6WT4j2+BMArCP7Wp3AN9dtWAaRYE aznMO0nvfYvZD9fX7442JQVaY5rBXTzZVudf2VrJbFp1VjAmsqzrF8hYJf6b2Bw/SSL5NhERJvg nohjNKeuQgIiHzDPJhYLc0ImKFna3zN7r6qZZgyj85+MStTJn03S4Gjx//KhAz7VwTYzGjOEDT+ mYOXCG4E5vMDTrPFXcGy6Q/6pP5nlVvI= X-Received: by 2002:a05:693c:2c13:b0:2a6:a306:efdb with SMTP id 5a478bee46e88-2c0e46d3fc8mr493338eec.3.1773776473996; Tue, 17 Mar 2026 12:41:13 -0700 (PDT) X-Received: by 2002:a05:693c:2c13:b0:2a6:a306:efdb with SMTP id 5a478bee46e88-2c0e46d3fc8mr493316eec.3.1773776473339; Tue, 17 Mar 2026 12:41:13 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:993e::75d? ([2804:14d:8084:993e::75d]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2c0e536894bsm769861eec.5.2026.03.17.12.41.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Mar 2026 12:41:12 -0700 (PDT) Message-ID: <93ef9c09-1269-43ae-aa3f-28aff7aadaa1@redhat.com> Date: Tue, 17 Mar 2026 16:41:07 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCHv2] gdb: notify of inferior switch when needed from 'thread' command To: Andrew Burgess , gdb-patches@sourceware.org References: <106ee09a80eac0dcc72d134dbf02f567de7163ce.1769435821.git.aburgess@redhat.com> From: Guinevere Larsen In-Reply-To: <106ee09a80eac0dcc72d134dbf02f567de7163ce.1769435821.git.aburgess@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: wKIipImbQBHsKDBaOT2dwvZt0iNowMME9JSB4owhuZM_1773776475 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 1/26/26 10:58 AM, Andrew Burgess wrote: > In v2: > > - Rebased and retested. > > - Reworked commit message to try and address Pedro's concerns. > > Thanks, > Andrew > > --- Hi Andrew! I've taken a look at this patch and it looks pretty good, and I think it is a good change. I know you're waiting for Pedro's feedback, but hopefully this message acts as a ping for him as well as a review for you Reviewed-By: Guinevere Larsen > > 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 effects 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 included > 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 notify_user_selected_context_changed. > > Currently, 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 that 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. > --- > gdb/mi/mi-main.c | 44 ++++++++++++--- > .../gdb.mi/user-selected-context-sync.exp | 56 ++++++++++++++++--- > gdb/thread.c | 13 ++++- > 3 files changed, 93 insertions(+), 20 deletions(-) > > diff --git a/gdb/mi/mi-main.c b/gdb/mi/mi-main.c > index 77e56bc9fc8..a18209366ff 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,12 +1973,30 @@ struct user_selected_context > > /* Return true if the user selected context has changed since this object > was created. */ > - bool has_changed () const > + 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; > @@ -1982,7 +2005,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 > @@ -1991,10 +2014,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 > @@ -2098,10 +2121,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 3434ffa2a46..4f02b950f6e 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/thread.c b/gdb/thread.c > index 0788bea235a..9ca1a8d973a 100644 > --- a/gdb/thread.c > +++ b/gdb/thread.c > @@ -1983,10 +1983,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: 449035c35f2169e0c690d83f28306275ab7f7463 -- Cheers, Guinevere Larsen It/she