From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23742 invoked by alias); 23 Jan 2020 14:58:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 23734 invoked by uid 89); 23 Jan 2020 14:58:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Jan 2020 14:58:07 +0000 Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (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 296C01E648; Thu, 23 Jan 2020 09:58:05 -0500 (EST) Subject: Re: [PATCH v2 2/4] Unregister the last inferior from the event loop To: "Maciej W. Rozycki" Cc: Pedro Alves , gdb-patches@sourceware.org, Jim Wilson References: <2f8d9a63-db38-e5c0-d221-dd9b1e151e1b@simark.ca> <323e416c-f0a9-ec14-c279-508c0245a479@simark.ca> From: Simon Marchi Message-ID: Date: Thu, 23 Jan 2020 16:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-01/txt/msg00732.txt.bz2 On 2020-01-22 9:33 p.m., Maciej W. Rozycki wrote: > On Thu, 23 Jan 2020, Maciej W. Rozycki wrote: > >> This change (2/4) can therefore be dropped as no longer required. Again, >> thank you, Simon, for your assistance! > > On second thoughts and having experimented a bit I take my conclusion > back. > > I think we do want to include my proposed change so as not to have the > value of 1 linger in `infrun_is_async' after an abrupt termination of the > target connection. This is because it is not the case if a remote stub > behaves in an orderly manner, where `infrun_is_async' is reset to 0 every > time execution stops in the debuggee (in the scenario concerned, that is). > > Therefore I think we want the state of GDB to be consistently the same > regardless of whether the remote connection has been ended with `detach', > `disconnect', `kill' or abruptly, even though we currently do not know > (anymore) of any observable difference in behaviour resulting from this > discrepancy. > > OK to go ahead with this change then? > > NB the current session log looks like: > > (gdb) continue > Continuing. > infrun: clear_proceed_status_thread (Thread 2061.2061) > infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) > Sending packet: $Z0,1555560ad8,2#7c...Packet received: > Packet Z0 (software-breakpoint) is NOT supported > Sending packet: $m1555560ad8,2#33...Packet received: 8280 > Sending packet: $X1555560ad8,0:#56...Packet received: OK > binary downloading supported by target > Sending packet: $X1555560ad8,2:\002\220#ea...Packet received: OK > infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current > thread [Thread 2061.2061] at 0x1555556ef0 > Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a...Packet received: OK > Sending packet: $vCont?#49...Packet received: vCont;c;C;t > Packet vCont (verbose-resume) is supported > Sending packet: $vCont;c:p80d.-1#aa...infrun: infrun_async(1) > infrun: prepare_to_wait > ^Cremote_pass_ctrlc called > remote_interrupt called > ^Cremote_pass_ctrlc called > infrun: infrun_async(0) > The target is not responding to interrupt requests. > Stop debugging it? (y or n) y > infrun: infrun_async(1) > Disconnected from target. > (gdb) > > Maciej > I think it would make sense. I was wondering about how your change would behave with multiple targets, but it only triggers when there are no more live inferiors across all targets, so I think it would be fine. But in all honesty, I don't really understand what the infrun_is_async variable is for. Clearly, it makes it so this: if (enable) mark_async_event_handler (infrun_async_inferior_event_token); else clear_async_event_handler (infrun_async_inferior_event_token); is only called when there is a transition (async becomes enabled or becomes disabled), but I don't see why that is particularly important. Simon