From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UH1LLZ3ChV8qCwAAWB0awg (envelope-from ) for ; Tue, 13 Oct 2020 11:07:09 -0400 Received: by simark.ca (Postfix, from userid 112) id B67041EF6F; Tue, 13 Oct 2020 11:07:09 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C6A9D1E58E for ; Tue, 13 Oct 2020 11:07:07 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 840C13851C15; Tue, 13 Oct 2020 15:07:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 840C13851C15 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1602601627; bh=bffEVBwNPEFao/fBukXufb77gSAFdvCLk+l1UPqBI7w=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=VdzvwB7MN1k0GPPQ6eiwpmCDbcpjKUCeXrByndzyzI073EXS8Y8KOThUmMKaoISA/ lHXVMHA27I3a76KU1bOk6JBiiGHG+6yCPk3bFgMqjAywPOrZ/KTLl7Vhk/Cun+lFqP fCUbF/hJOQsFCtP9NZh4LHSUKxwfWxuHnlJr0bow= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id B71A33851C15 for ; Tue, 13 Oct 2020 15:07:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B71A33851C15 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 09DF6ss8011422 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Oct 2020 11:06:58 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 09DF6ss8011422 Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (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 8772A1E58E; Tue, 13 Oct 2020 11:06:52 -0400 (EDT) Subject: Re: [PATCH] gdb: don't pass TARGET_WNOHANG to targets that can't async (PR 26642) To: Pedro Alves , gdb-patches@sourceware.org References: <20201001025656.2561757-1-simon.marchi@polymtl.ca> <2fc59140-0fb4-cab3-a816-2abc95116387@palves.net> Message-ID: <518fc763-c94d-c987-0bc8-0be3c2e3a6f6@polymtl.ca> Date: Tue, 13 Oct 2020 11:06:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <2fc59140-0fb4-cab3-a816-2abc95116387@palves.net> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 13 Oct 2020 15:06:54 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2020-10-12 10:48 a.m., Pedro Alves wrote: >> 2. the infrun async handler is marked in prepare_to_wait, to immediatly > > immediatly -> immediately Fixed. >> 2. the infrun async handler is marked in prepare_to_wait, to immediatly > > Ditto. Fixed. >> We end up in this situation because these two necessary conditions are >> met: >> >> 1. GDB uses the TARGET_WNOHANG option with a target that can't do async. >> I don't think this makes sense. I mean, it's technically possible, >> the doc for TARGET_WNOHANG is: >> >> /* Return immediately if there's no event already queued. If this >> options is not requested, target_wait blocks waiting for an >> event. */ >> TARGET_WNOHANG = 1, >> >> ... which isn't in itself necessarily incompatible with synchronous >> targets. But I don't see when it would be useful to ask a sync >> target to do a non-blocking wait. > > I could imagine it being useful to implement async mode for targets that > can poll for events, but don't have a native asynchronous "there's a new event!" > mechanism (like SIGCHLD or similar). So GDB could poll for events > periodically, say, with a timer via the event loop. Windows could gain > async support that way. Makes sense. >> - Do we ever need to do a blocking wait on a target that supports >> async? > > Yes, for example in prepare_for_detach, we do a blocking wait > (via do_target_wait). I think all such loops could likely be > converted to go via a nested event loop, which may be better for > handling user input events at the same time. But regardless, I wouldn't > be conformable with trying can_async_p with what a specific target_wait > call wants. Seems best to me to keep them orthogonal. Ok. I would see it as a nice simplification for implementing target to only have to implement one model, so that async targets don't have to think about a way to block (which can be implemented as a nested event loop like stop_all_threads does). But indeed that's not necessary. >> So, could we make it so that if target's can_async_p method returns >> true, its wait method is necessarily non-blocking? And if >> can_async_p returns false, its wait method is necessarily blocking? > > I'd rather not. Ok. >> >> It sounds to me like it would simplify the semantic of >> target_ops::wait a little bit. >> >> >> 2. The linux-nat target, even in the mode where it emulates a >> synchronous target (with "maintenance set target-async off") respects >> TARGET_WNOHANG. >> >> Non-async targets, such as windows_nat_target, simply don't check / >> support TARGET_WNOHANG. Their wait method is always blocking. So, >> to properly emulate a non-async target, I believe that linux-nat >> should also ignore it when in "maintenance set target-async off" >> mode. Its behavior would be closer to a "true" non-async target. >> >> The problem disappears if we simply fix either of these issues, but I >> think it wouldn't hurt to fix both. > > Unless there's a need otherwise, it would seem better to me to > just fix the common code to not request a non-blocking wait out > of !async targets. I don't think there's any good reason to complicate > (however little) linux-nat.c to handle a scenario that doesn't exist. Hmm, right, with the assert in target_wait, it should never happen. And if we make it valid to do non-blocking polls of non-async targets, as you described we could do for Windows above, then it could become a valid case I suppose. >> diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c >> index fbb538859429..1064fc4f8c72 100644 >> --- a/gdb/linux-nat.c >> +++ b/gdb/linux-nat.c >> @@ -3238,7 +3238,11 @@ linux_nat_wait_1 (ptid_t ptid, struct target_waitstatus *ourstatus, >> >> /* No interesting event to report to the core. */ >> >> - if (target_options & TARGET_WNOHANG) >> + /* If target_async_permitted is false (maintenance set target-async off >> + is used), pretend that we don't know about TARGET_WNOHANG and go block >> + in wait_for_signal. */ >> + if (target_options & TARGET_WNOHANG >> + && target_async_permitted) > > I'd rather go without this hunk. Would it still fix things? Yes, since infrun won't ask linux-nat to TARGET_WNOHANG when target_async_permitted is false. I'll remove it, since it can never happen with the assert in target_wait. If anything, we could put an assert here as a double-check, if you think it could help. >> diff --git a/gdb/target.c b/gdb/target.c >> index dd78a848caec..6f340678b7ca 100644 >> --- a/gdb/target.c >> +++ b/gdb/target.c >> @@ -1997,6 +1997,11 @@ ptid_t >> target_wait (ptid_t ptid, struct target_waitstatus *status, >> target_wait_flags options) >> { >> + target_ops *target = current_top_target (); >> + >> + if (!target->can_async_p ()) > > Why not call "!target_can_async_p ()" instead? It's exactly > the same. I prefer the version where we don't hide the uses of current_whatever, instead going slowly towards passing them as parameters instead. >> + gdb_assert ((options & TARGET_WNOHANG) == 0); >> + >> return current_top_target ()->wait (ptid, status, options); > > Perhaps you meant to adjust this to do "target->wait" instead? Yes, done. >> diff --git a/gdb/testsuite/gdb.base/maint-target-async-off.exp b/gdb/testsuite/gdb.base/maint-target-async-off.exp >> new file mode 100644 >> index 000000000000..e77bc79a21e1 >> --- /dev/null >> +++ b/gdb/testsuite/gdb.base/maint-target-async-off.exp >> @@ -0,0 +1,32 @@ >> +# Copyright 2020 Free Software Foundation, Inc. >> + >> +# This program is free software; you can redistribute it and/or modify >> +# it under the terms of the GNU General Public License as published by >> +# the Free Software Foundation; either version 3 of the License, or >> +# (at your option) any later version. >> +# >> +# This program is distributed in the hope that it will be useful, >> +# but WITHOUT ANY WARRANTY; without even the implied warranty of >> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> +# GNU General Public License for more details. >> +# >> +# You should have received a copy of the GNU General Public License >> +# along with this program. If not, see . >> + >> +# Verify that debugging with "maintenance target-async off" works somewhat. At >> +# least running to main and to the end of the program. >> + >> +standard_testfile >> + >> +if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } { >> + return >> +} >> + >> +gdb_test_no_output "maintenance set target-async off" > > I don't think this works correctly > with --target_board=native-extended-gdbserver, since by the time you > get here, the remote connection is already set up. > > I think the best way to handle that is to do the same we do what > non-stop testcases do: > > save_vars { GDBFLAGS } { > append GDBFLAGS " -ex \"set non-stop $nonstop\"" > clean_restart ${executable} > } Done. I'll send a v2 shortly. I was wondering, do you see a better way to fix this than what I did in do_target_wait_1, forcing TARGET_WNOHANG to off? It doesn't feel right to have the caller ask for something and just do something else. But I couldn't think of anything better (that's also suitable for the release branch, at least). Simon