From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id zIKbJRkUm2rkJikAWB0awg (envelope-from ) for ; Fri, 04 Sep 2026 14:55:21 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=palves.net header.i=@palves.net header.a=rsa-sha256 header.s=dreamhost header.b=ZZLkEmto; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 658531E033; Fri, 04 Sep 2026 14:55:21 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (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 279D01E033 for ; Fri, 04 Sep 2026 14:55:16 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5AA774BB588A for ; Fri, 4 Sep 2026 18:55:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5AA774BB588A Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=palves.net header.i=@palves.net header.a=rsa-sha256 header.s=dreamhost header.b=ZZLkEmto Received: from toucan.tulip.relay.mailchannels.net (toucan.tulip.relay.mailchannels.net [23.83.218.254]) by sourceware.org (Postfix) with ESMTPS id 838EC4BB5886 for ; Fri, 4 Sep 2026 18:54:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 838EC4BB5886 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=palves.net ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 838EC4BB5886 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=23.83.218.254 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788548090; cv=none; b=Ls3pkMGT4NBHwCyGpu+rqmVQLpUB/cj2o5BMv7fzKTUpf6tBxDF6fN8rN22ci4MUYyAw0rlKG4El0yPBK3jCTQBn6Xch0yTEC343mqQygcM0tey8wzGYpJT8urYxaXB7Mq4onk/MHvGFbqkYjqmqIIYWDTMW8WtD9IdMbPDHdNs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788548090; c=relaxed/simple; bh=q7jqerBW6KLQDlujufcsaCFqk4aOp4Q/qNf8pYsxNU4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=lEM4nUTy0k8ZSukLZP0dRNZ79NA1WnoeKo0O+s5KQrSj2m8Nc4WcWdMWWgq1eWVozCSsulcvZKkXjKu+mJZ++mF4CRdZxuH7lpPbh7KpIMHl7TY1Nm5Lh/v7SOQm/ATKVTmQXoBXp3v7CtfahBV21sSN5jiKJfLTjLKlyWqY7WI= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=palves.net header.i=@palves.net header.a=rsa-sha256 header.s=dreamhost header.b=ZZLkEmto DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 838EC4BB5886 X-Sender-Id: dreamhost|x-authsender|pedro@palves.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 588294040EC; Fri, 04 Sep 2026 18:54:48 +0000 (UTC) Received: from pdx1-sub0-mail-a227.dreamhost.com (100-96-173-63.trex-nlb.outbound.svc.cluster.local [100.96.173.63]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 0ED534034CA; Fri, 04 Sep 2026 18:54:48 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|pedro@palves.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|pedro@palves.net X-MailChannels-Auth-Id: dreamhost X-Macabre-Cure: 2ddca332278aae96_1788548088138_2242807355 X-MC-Loop-Signature: 1788548088138:3440056105 X-MC-Ingress-Time: 1788548088138 Received: from pdx1-sub0-mail-a227.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.96.173.63 (trex/8.0.2); Fri, 04 Sep 2026 18:54:48 +0000 Received: from [192.168.0.201] (bl22-81-37.dsl.telepac.pt [2.83.81.37]) (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) (Authenticated sender: pedro@palves.net) by pdx1-sub0-mail-a227.dreamhost.com (Postfix) with ESMTPSA id 4hc5HV2Tpwz1QL; Fri, 4 Sep 2026 11:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=palves.net; s=dreamhost; t=1788548087; bh=dF9viBWWvRiaBankAPU4adRS1WO1wFLPF5VWwMDS7gA=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=ZZLkEmtoYWMwmY4U93F8hCNf5vrEK7GZXjRu20+ijx1AMfiu66RAP/uiYWleaVwts JfY0Q49uu9xuNINwlBexq59r2mCRKiodp5nbt5wIuo5PT9qQMArbxEl0PdgDW96z7b 9IjIVHdU4vs6qfOdA/XUY8CvBJU4bJMW+gEiyTyyu9C4hea/xOP8X3jKFkiVH2MAcs 6pSN/dY2z3oS/Jnhv04WeTU/DSV3bK43nwJZx2tjtwwvahSJEEQiY23GeFhXJOYA+w RE0awFkL+bAfKg9L7Z6ydRAvEwpVIqgJ7AXLGrr1DciJopwrQAdngJC4vzMiUOUQuK zqWnFQl/4fn7g== Message-ID: <42bc9fd0-1396-494e-b7af-a5af10a94172@palves.net> Date: Fri, 4 Sep 2026 19:54:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 00/11] Add AlwaysNonStop remote protocol extension To: Tom Tromey , Mohamed Bouhaouel Cc: gdb-patches@sourceware.org, markus.t.metzger@intel.com, stephan.rohr@intel.com, eliz@gnu.org, aburgess@redhat.com References: <20260714092128.12941-1-mohamed.bouhaouel@intel.com> <87jyp028ux.fsf@tromey.com> From: Pedro Alves Content-Language: en-US In-Reply-To: <87jyp028ux.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 2026-09-04 19:02, Tom Tromey wrote: >>>>>> Mohamed Bouhaouel writes: > >> This series introduces the AlwaysNonStop extension, enabling remote >> stubs to declare preferable non-stop mode operation. When advertised, >> GDB defaults to non-stop mode. Attempts to disable it might be rejected >> by the stub with a descriptive error message. > > One thing I don't see in the series is the motivation for this. > It doesn't seem like something that would be useful to a user. > > And if a server wants to work in all-stop-on-top-of-non-stop mode, > I don't think there's really anything preventing that; but also this > wouldn't require any kind of protocol extension. > > I looked at this a little but I'm perhaps not the best person to review > it. I can take a stab at some of it at some point; but I would like to > understand the purpose. > FWIW, I discussed the design that led to this with Mohamed and others off-list, and I do plan to review it once I'm able. I'll try to give it a shot next week. The main purpose is that Intel's GPU support is designed as combining two inferiors, one for the CPU side, and one for the GPU side. The CPU side is a standard linux-nat target, which runs in all-stop-on-top-of-non-stop (AS-NS). The GPU side is based on a remote gdbserver connection. Combining a non-stop (native) with an all-stop (remote/gdbserver) target is something that infrun is not really prepared for. So I've suggested that instead, it'll be better if Intel's gdbserver always works in non-stop mode, too. There is really currently no way for the server to tell GDB that it wants to work in that way. Users would have to set "maint set target-non-stop on" manually. AS-NS on the remote side has some user-visible advantages. The AS variant of the protocol doesn't let you talk to the remote side until the target next stops, for example. so no setting breakpoints, no reading global variables, etc., none of that is possible while the target is running, while it is, in AS-NS. The main difference is that vCont is asynchronous in the non-stop remote protocol. So ideally, we'd switch over to that variant when we can, by default. But since there are limitations (the ones I listed in the discussion of a previous revision of this series), a remote target reporting that is supports non-stop mode, should not be taken as meaning that it prefers to use non-stop mode by default. That's what the new extension gives us, a way for the remote target to tell GDB what it wants. I ran out of time this week, but I'll try to look at this soon. And of course, others shouldn't be discouraged from looking just because I said I would. The more eyes, the better. Pedro Alves