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 244A23858D32 for ; Mon, 29 May 2023 14:53:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 244A23858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.170] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id E26A81E0D4; Mon, 29 May 2023 10:53:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1685372006; bh=VWJj6Pf39s6esFmSsF5ClhDfgEEjWaTplZWP/8F6ccw=; h=Date:Subject:To:References:From:In-Reply-To:From; b=cW7svY697BftP1bDJO9QIhPXb38NWv9xWQclmmuVZTXAOtNeegjs1WlmVMs67DW8v q6m6HujWc8642fnUAmsW+n3IyYbLOXUPx8oCKwnoYrrObRLPNZ+6V8Kucwojc893Yj H5AFJ436mwoa8jgzKm2W/qUfp+3d3npIEmrupMr8= Message-ID: <8ce71d29-79e1-2d81-813a-18ecb905169f@simark.ca> Date: Mon, 29 May 2023 10:53:25 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.1 Subject: Re: [PATCH 01/30] gdb/mi: fix ^running record with multiple MI interpreters Content-Language: fr To: Simon Marchi , gdb-patches@sourceware.org References: <20230502205011.132151-1-simon.marchi@efficios.com> <20230502205011.132151-2-simon.marchi@efficios.com> From: Simon Marchi In-Reply-To: <20230502205011.132151-2-simon.marchi@efficios.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 5/2/23 16:49, Simon Marchi via Gdb-patches wrote: > I stumbled on the mi_proceeded and running_result_record_printed > globals, which are shared by all MI interpreter instances (it's unlikely > that people use multiple MI interpreter instances, but it's possible). > After poking at it, I found this bug: > > 1. Start GDB in MI mode > 2. Add a second MI interpreter with the new-ui command > 3. Use -exec-run on the second interpreter > > This is the output I get on the first interpreter: > > =thread-group-added,id="i1" > ~"Reading symbols from a.out...\n" > ~"New UI allocated\n" > (gdb) > =thread-group-started,id="i1",pid="94718" > =thread-created,id="1",group-id="i1" > ^running > *running,thread-id="all" > > And this is the output I get on the second intepreter: > > =thread-group-added,id="i1" > (gdb) > -exec-run > =thread-group-started,id="i1",pid="94718" > =thread-created,id="1",group-id="i1" > *running,thread-id="all" > > The problem here is that the `^running` reply to the -exec-run command > is printed on the wrong UI. It is printed on the first one, it should > be printed on the second (the one on which we sent the -exec-run). > > What happens under the hood is that captured_mi_execute_command, while > executing a command for the second intepreter, clears the > running_result_record_printed and mi_proceeded globals. > mi_about_to_proceed then sets mi_proceeded. Then, mi_on_resume_1 gets > called for the first intepreter first. Since the > > !running_result_record_printed && mi_proceeded > > condition is true, it prints a ^running, and sets > running_result_record_printed. When mi_on_resume_1 gets called for the > second interpreter, running_result_record_printed is already set, so > ^running is not printed there. > > It took me a while to understand the relationship between these two > variables. I think that in the end, this is what we want to track: > > 1. When executing an MI command, take note if that command causes a > "proceed". This is done in mi_about_to_proceed. > 2. In mi_on_resume_1, if the command indeed caused a "proceed", we want > to output a ^running record. And we want to remember that we did, > because... > 3. Back in captured_mi_execute_command, if we did not output a > ^running, we want to output a ^done. > > Moving those two variables to the mi_interp struture appears to fix it. > Only for the interpreter doing the -exec-run command does the > running_result_record_printed flag get cleared, and therefore only or > that one does the ^running record get printed. > > Add a new test for this, that does pretty much what the reproducer above > shows. Without the fix, the test fails because > mi_send_resuming_command_raw never sees the ^running record. > > Change-Id: I63ea30e6cb61a8e1dd5ef03377e6003381a9209b I pushed just this patch on its own. The rest of the series conflicts in non-trivial ways with new stuff in master. Simon