From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 36BE23857404 for ; Mon, 21 Mar 2022 20:35:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 36BE23857404 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.95] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B303E1F0BB; Mon, 21 Mar 2022 16:35:48 -0400 (EDT) Message-ID: <78570a7f-f6c0-5e1b-4178-c9ce401feab7@simark.ca> Date: Mon, 21 Mar 2022 16:35:48 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [pushed] gdb/mi: consistently notify user when GDB/MI client uses -thread-select Content-Language: tl To: Jan Vrany , gdb-patches@sourceware.org Cc: Andrew Burgess References: <20220316150914.1254897-1-jan.vrany@labware.com> From: Simon Marchi In-Reply-To: <20220316150914.1254897-1-jan.vrany@labware.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3639.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2022 20:35:52 -0000 On 2022-03-16 11:09, Jan Vrany via Gdb-patches wrote: > GDB notifies users about user selected thread changes somewhat > inconsistently as mentioned on gdb-patches mailing list here: > > https://sourceware.org/pipermail/gdb-patches/2022-February/185989.html > > Consider GDB debugging a multi-threaded inferior with both CLI and GDB/MI > interfaces connected to separate terminals. > > Assuming inferior is stopped and thread 1 is selected, when a thread > 2 is selected using '-thread-select 2' command on GDB/MI terminal: > > -thread-select 2 > ^done,new-thread-id="2",frame={level="0",addr="0x00005555555551cd",func="child_sub_function",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="30",arch="i386:x86-64"} > (gdb) > > and on CLI terminal we get the notification (as expected): > > [Switching to thread 2 (Thread 0x7ffff7daa640 (LWP 389659))] > #0 child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30 > 30 volatile int dummy = 0; > > However, now that thread 2 is selected, if thread 1 is selected > using 'thread-select --thread 1 1' command on GDB/MI terminal > terminal: > > -thread-select --thread 1 1 > ^done,new-thread-id="1",frame={level="0",addr="0x0000555555555294",func="main",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="66",arch="i386:x86-64"} > (gdb) > > but no notification is printed on CLI terminal, despite the fact > that user selected thread has changed. > > The problem is that when `-thread-select --thread 1 1` is executed > then thread is switched to thread 1 before mi_cmd_thread_select () is > called, therefore the condition "inferior_ptid != previous_ptid" > there does not hold. > > To address this problem, we have to move notification logic up to > mi_cmd_execute () where --thread option is processed and notify > user selected contents observers there if context changes. > > However, this in itself breaks GDB/MI because it would cause context > notification to be sent on MI channel. This is because by the time > we notify, MI notification suppression is already restored (done in > mi_command::invoke(). Therefore we had to lift notification suppression > logic also up to mi_cmd_execute (). This change in made distinction > between mi_command::invoke() and mi_command::do_invoke() unnecessary > as all mi_command::invoke() did (after the change) was to call > do_invoke(). So this patches removes do_invoke() and moves the command > execution logic directly to invoke(). > > With this change, all gdb.mi tests pass, tested on x86_64-linux. > > Co-authored-by: Andrew Burgess > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20631 Hi, I see this on Ubuntu 20.04, am I the only one? FAIL: gdb.mi/user-selected-context-sync.exp: mode=all-stop: test_mi_thread_select: thread 1.2: -thread-select again, event on CLI, ensure no output CLI FAIL: gdb.mi/user-selected-context-sync.exp: mode=all-stop: test_mi_thread_select: thread 1.3: -thread-select again, event on CLI, ensure no output CLI FAIL: gdb.mi/user-selected-context-sync.exp: mode=non-stop: test_mi_thread_select: thread 1.2: -thread-select again, event on CLI, ensure no output CLI Just the first one here: -thread-select 2 ^done,new-thread-id="2",frame={level="0",addr="0x00005555555551b8",func="child_sub_function",args=[],file="/home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.mi/user-selected-context- sync.c",fullname="/home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="33",arch="i386:x86-64"} (gdb) PASS: gdb.mi/user-selected-context-sync.exp: mode=all-stop: test_mi_thread_select: thread 1.2: -thread-select again [Switching to thread 1.2 (Thread 0x7ffff7d99700 (LWP 1763981))] #0 child_sub_function () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:33 33 dummy = !dummy; /* thread loop line */ print 666 $9 = 666 (gdb) FAIL: gdb.mi/user-selected-context-sync.exp: mode=all-stop: test_mi_thread_select: thread 1.2: -thread-select again, event on CLI, ensure no output CLI Simon