From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id R3LADs7nLWVN1y8AWB0awg (envelope-from ) for ; Mon, 16 Oct 2023 21:47:58 -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=DukcoQOO; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 32C2E1E0C1; Mon, 16 Oct 2023 21:47:58 -0400 (EDT) Received: from server2.sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (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 191D31E091 for ; Mon, 16 Oct 2023 21:47:56 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 84E4C385840B for ; Tue, 17 Oct 2023 01:47:55 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id CBFA33858C66 for ; Tue, 17 Oct 2023 01:47:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CBFA33858C66 Authentication-Results: sourceware.org; dmarc=pass (p=none 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 CBFA33858C66 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=1697507258; cv=none; b=uRj4QFJTgC8SgxeBCVP0EmK8lo/QQ+jStpUOvinWFvm5fCXFYEPfQymT+edbF2Z4TSq+kuLwdHHwpf4Q2/HuqCMdBPsg5mcZNotd6StetkoOJpxvC7vAY0fO6NsvwHLO60eizBZfvXh0pwafQd6HmlzipQ2YwwPAnv8en5ydino= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697507258; c=relaxed/simple; bh=GA80EbsOHzv0cSf28QWmc7/dtlqp4jbk+cVwKzTXnRU=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=uoI+W6FppvTmRaPu4jVtWGwhQ5qCuy8qkfPOqcxTaKKZ9oTjODK8DMgjsSH6TvHdH9jgr7KdNVRyFXqfyI6dB6WpjgJ5GgbUhu3hWcIcF1k409c/LKTGatWZXQ3RYYfBeoydXkzAN4MGPZnzWwjRNHKqo161fBcCF1KlhhYdaUg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1697507256; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nBiaCVapHd7ojTBM5ctbxzjr/mRmbAlCs/cingGZX6w=; b=DukcoQOOPCotwqmMU7yYJjwClh5izfwn/XcRLaVjwj7P6sklowjPClFfo8XtuPRjYH6m22 nXTboz6Ps8pXyAS1/ihVGzyaXD9PcmHoHszp6SelJGRE8YpcPIu4EtUPoxk0goCqJsjFWY D6+avvS2+7N3lF3yTnL+gE3ySWcNhfU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-433-LInxXAviMLmeCUzIkqAS4w-1; Mon, 16 Oct 2023 21:47:34 -0400 X-MC-Unique: LInxXAviMLmeCUzIkqAS4w-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4938C185A79C; Tue, 17 Oct 2023 01:47:34 +0000 (UTC) Received: from f38-zws-nv (unknown [10.22.16.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 05C1E1C060AE; Tue, 17 Oct 2023 01:47:33 +0000 (UTC) Date: Mon, 16 Oct 2023 18:47:32 -0700 From: Kevin Buettner To: Shivam Saxena Cc: gdb-patches@sourceware.org Subject: Re: [RFC] [PATCH] [PR gdb/29796] Fix gdbserver delay before quitting in extended-remote Message-ID: <20231016184732.5e7da998@f38-zws-nv> In-Reply-To: References: <20231014195236.2b0241c9@f37-zws-nv> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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 Sun, 15 Oct 2023 16:33:16 +0000 Shivam Saxena wrote: > >> Investigating PR29796, where it was noticed that there was a delay whe= n trying to quit the gdb session if connected to gdbserver via stdio. It wa= s also mentioned that using --once=E2=80=8B when launching gdbserver=E2=80= =8B would fix this problem and a recommendation was made to always apply --= once=E2=80=8B when launching gdbserver=E2=80=8B with stdio=E2=80=8B. > >> > >> I've explicitly set the run_once=E2=80=8B flag when stdio=E2=80=8B is = detected at launch of gdbserver. This does fix the problem as suggested in = the bug since the conditional at gdbserver/server.cc:3958=E2=80=8B is alway= s triggered. > >> ``` > >> if (run_once || (!extended_protocol && !target_running ())) > >> throw_quit ("Quit"); > >> ``` > >> However, would it be better to create a new flag for this to=20 > >> facilitate quitting despite extended_protocol=E2=80=8B instead of pigg= ybacking on --once=E2=80=8B logic? =20 >=20 > > I don't see a problem with using 'run_once' for this purpose. But if t= here's something I'm missing, please explain... =20 >=20 > By the conditional it seems the intent was to not allow quitting immediat= ely if in extended protocol mode. We are adding another condition to quit -= if launched in stdio. But nothing in this logic alone would make that appa= rent. (no comment, no flag). I thought this reduced traceability. But I mig= ht be overthinking things. So if the fix seems fine for this purpose I'll f= ix the patch and reply. It seems I might have to use a different email acco= unt to submit the patch via git send-email.=20 I think it's fine. (But don't forget to fix the nit that I found regarding the comment.) Kevin