From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BlfCGdeqiWmUWTEAWB0awg (envelope-from ) for ; Mon, 09 Feb 2026 04:37:27 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=C4F97/ii; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 500D61E089; Mon, 09 Feb 2026 04:37:27 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.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,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.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 21A2A1E089 for ; Mon, 09 Feb 2026 04:37:26 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 873394CF2EF9 for ; Mon, 9 Feb 2026 09:37:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 873394CF2EF9 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=C4F97/ii Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [IPv6:2607:f8b0:4864:20::112f]) by sourceware.org (Postfix) with ESMTPS id 40EDD4B920C9 for ; Mon, 9 Feb 2026 09:36:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 40EDD4B920C9 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 40EDD4B920C9 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2607:f8b0:4864:20::112f ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1770629819; cv=pass; b=s/WaifivJGay2mPBl61YoM6a9vZlPOoTG7zOMJdFEwSqU0aH+a00It0dV0686f2cbPECxORj0ne6MRAE8K1hcDaSfdIQ1tpvj15SWrMNVC5vf1f5VUInhSqNTI3Hdy51IUi6t9ueTm7BjIT9iqTA1/+eduIKGEtGlYgBlWYuPOI= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1770629819; c=relaxed/simple; bh=AU3zRrTGk1AggDV7KvQXzbBELywoPEIXXSSsX3lIImw=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=EekssRjfAFhX0+RxNNa4rmhWRlwMJLUoul5bslw54h2rSH479lOzNKw5D7njewfa7u/uOky2EQ2sOyXeKS/L5VaKQOQSwWH75pKnYbd+aWIUNsZJPux2eal3T2k90Losy0rh5jFKUZOhOu7m1R44p3hf1oth3uZULYQn9uUD0p4= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 40EDD4B920C9 Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-790992528f6so37581637b3.1 for ; Mon, 09 Feb 2026 01:36:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770629818; cv=none; d=google.com; s=arc-20240605; b=L8vkBrZItXx+1mS+8PZR20aVZtb4G/xY3DBnngFP0BuL7vya8Cow4+arlfgnB3xp79 BluoNkh11/mfEM2pUARQFEvJthOCi/i4cW/7x8+ZZ5zMEuNXHWaXW3PBcdjLxNiLK6P6 ZUDq40334zt1dnmOspGyRWuhi+XxULgfvCJYWDzMv4+z9z3EA/DvBT1poilTKPYaoMaQ pfzn7j1IEF9KjhsXl8W8XaWF3cmHli5fX960sJLR0F1yCTalPH6SF5GUaIDgeKP+Ra7F mlw0M13jE3Fvfvzsb+PptJi6cz/8ZN2eBpC10tKu9Dls06OfazzEe2m88j15XwK+6IWC xglA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=gmKBsrVNv0k1zrCpv3CL01SXu/Tq4nA3YJ1TqztuNug=; fh=IbnlJmMARMsicHKe8AhDmIyoH4xi04g8H/HrmWB6vJA=; b=XNZFsskSEshb43D8LrysG4c27xfSVAPjojHs8sytE69ps9n/w8QJ6z+ZOCtYSL4AJ+ lNB38K8wJPpRy/8v8PpuizVZxx26+HiOcHlO2u6GOA6n3u81uKAH0t2eVajmoKj3xCOt FQUVAZjx4uLRTtBgs2CDIAjAyBUpemvDwvJasFNOKHAKZ56W9ie3vzSBq0cYX9VsWir6 ONq1+QDVgu4CA+lZ/ZkWJ/vgmQARnncZgjdEK2Du4yVwKAf3jEnU9cbCRbQIdI/9q5Qj NdQ9qMHFAfB/4mQyxtI/UxhEvQcKBnxE8uWpA7FtrYOZgwnfoePI/lYAPApfvzcHcAHh /Upg==; darn=sourceware.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1770629818; x=1771234618; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gmKBsrVNv0k1zrCpv3CL01SXu/Tq4nA3YJ1TqztuNug=; b=C4F97/iiwEKk+5YbMM+kHvaO4pkAwsQPNljlNNntv17ZrT1zI2PLzLY2behGO4bga2 dq7/jtxOfgeLw8XY/Z16vN20IyvskAG1bLYWR9EkFJuLV8k56psbZDd0yVp+3PKVGs5Q qWDpjuY0/faKyYeX3yX+zG53SfOa8I82QFvnHFkW6YVqXaf5blRI5Z88NaihQfWVElh+ ghtLjwly37TwZjOJXFrLqBYpE/zrDDPIX83XX3lJ+7loedmIFeN2QGq+1xZg3IZ8480G gJEOVomCL7MAtH8k5tlmBmvBKUIs6SUOYB7OkQ3EQU1RxRZ9gW9uL/GCv8hprVEWqhJR UV6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770629818; x=1771234618; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=gmKBsrVNv0k1zrCpv3CL01SXu/Tq4nA3YJ1TqztuNug=; b=bjZnZ4zkZls83kWTP2TB21/ripdq0dhDhRIR1XK61MR7c1EUu+7xhd/2IjybBWTNJk vqQZqpWD4mLwsrVjXch9PBpjGmkiRbPu2LXaO43qatKU7lZaFsoJLZ3Gm6PubJZSw51Y 92i0xszGRDjx5lbewph1WNaApRsGJRMYnTK1ZweUsuD3xXlXNU5bxzSHWCZ0xsU1r+pi hUtEjK0qp4nKy6fTke3sKgz4KRud8tPo+bYI7xeGYcATpzDsNGHm02pmlLSZquXpP7gs N7P8ayrz79o+/A/e9lvRevI306nOZhFQ/gTiHDndeUfaePAyFnCYC0uErIAu+mw0jhis Upeg== X-Gm-Message-State: AOJu0Yzy+c9+dhOkCI3waNlCVlbtqMm1DTNPASeie0OXUinwJPaalsne Nbuo16ErAzaKCYJdBvrqyqAFvfl0nA78DVrV4HroVC5aqQoap+fAFqDVmjbGmyI4OuhH52BEI6R d2udeXW2IepVMF8RE04K8nREi2E5MWShwkmx16RUQ9qlzg1y8L/02TeM= X-Gm-Gg: AZuq6aLJYgOjyX5U9ovqatsN7clxEj1n0tn1DI11VvDMfNL5RucNtSLRwxN4q1COrHo Uz/oEGwabiRwbYuc8+eNO2pOGl2OzaOjyEallecqzXNobJ/QNZJ1VWgIyLBLmVTSu+JfPtALjXj mhLOGos3SrW7rxZzdvnuqS9z2nBUmjrgnJ0szt8O3z4eVwn8xRIlusAVprtKpr7FhlwEvtk1Ge1 Xm0z/VNd1tuRUqywKfZE+9zm2i0vMGwwRXAd+taDsGF+ARWBz/PehaTupmoRXfNncO1OmH3rRz9 r/YqKamaugPwbdygTMX5GOhNVpwaG3w4HaIlyhBJj/WMgXJYsoyyfDI= X-Received: by 2002:a05:690c:fcd:b0:796:4f04:bbf2 with SMTP id 00721157ae682-7964f14070fmr10738907b3.63.1770629818530; Mon, 09 Feb 2026 01:36:58 -0800 (PST) MIME-Version: 1.0 References: <20260129181122.1426596-1-peter.maydell@linaro.org> <57424b3d-a34e-4fbe-9858-d45b8dd49150@gmail.com> In-Reply-To: <57424b3d-a34e-4fbe-9858-d45b8dd49150@gmail.com> From: Peter Maydell Date: Mon, 9 Feb 2026 09:36:46 +0000 X-Gm-Features: AZwV_QgDdoF6GdivHU4pWvGUCSghWnk9E1ql9pw1DG_XEtZScaZxCZm8ToAjOsk Message-ID: Subject: Re: [PATCH] docs: Clarify gdb remote protocol AArch64 SVE and SME handling To: Luis Cc: gdb-patches@sourceware.org, Thiago Jung Bauermann , Manos Pitsidianakis Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Mon, 2 Feb 2026 at 23:41, Luis wrote: > On 30/01/2026 09:36, Peter Maydell wrote: > > When I said "for the Z registers" that was a perhaps confusing > > simplification. SME's "streaming SVE" mode still requires all of: > > - the z regs > > - the p predicate regs > > - the ffr register > > - fpsr > > - fpcr > > (because streaming SVE gives you a subset of the SVE2 instruction set). > > > > The only thing that becomes in some sense duplicated is that the > > 'vg' pseudoregister in org.gnu.gdb.aarch64.sve will always read > > the same as the 'svg' pseudoregister in org.gnu.gdb.aarch64.sme, > > because the Z reg size is always the same as the ZA array size. > > But the debugger doesn't really need to care about that, as long > > as it consistently uses org.gnu.gdb.aarch64.sve 'vg' for the Z > > reg length and org.gnu.gdb.aarch64.sme 'svg' for the ZA array size > > (which it must do already for the SVE + SME case). > > > > Thanks for clarifying it. That makes more sense. > > >> It might be cleaner to clearly separate SVE and SME features, adding > >> Z registers to a SME feature if needed when SVE is disabled. Or > >> something similar to that. > > > > The disadvantage here is that instead of "SME only remote debug > > just works with the existing gdb" we get "you will need a new > > gdb that understands the new features". > > > > Remote debug *kinda* just works, unfortunately. In reality remote > debugging with SVE/SME is not properly supported because the remote > target cannot communicate vg/svg changes to gdb, and that messes things > up badly. The vg/svg won't generally change without gdb knowing about it, though -- presumably gdb could read it whenever the target stops, even if there's no mechanism for actively reporting a change ? > It might not be a big issue for SVE itself, as we don=C2=B4t usually chan= ge > vg mid-execution. But SME has SSVE and that tends to change vg/svg, so > it is more likely to run into issues. > > But yeah, putting that aside, I=C2=B4d definitely like to make things wor= k > with the current XML. Or make it work in a compatible way at least. > > >> I don't feel comfortable setting this is stone before we have a > >> patch that clarifies how this separation between SVE and SME is > >> achieved. > > > > I agree that we don't want to commit this until we're happy that > > it's the right thing. This patch is my attempt to put down in a > > concrete form how I think this should work. > > > > When you talk about "a patch that clarifies how this separation > > between SVE and SME is achieved", what do you mean? A patch to > > gdb? With this proposal, current gdb I think should work without > > changes. The changes Thiago has are all because of the way that > > the Linux ptrace API has chosen to represent SVE and SME, AIUI. > > We need a couple things from what I can see. > > First we need to teach gdb about SME without SVE, and that's what Thiago > is working on. I=C2=B4d like to see that patch first before we adjust the > documentation for the SME-but-no-SVE mode. Just to make sure things match= . > > The second one is addressing the remote debugging situation with the > changing vg/svg. Without that I'm afraid SVE/SME/SSVE remote debugging > will not go far. Yes, it will kinda work, but as soon as vg/svg changes > we will run into trouble. > > Until the second part is addressed, I'm a bit skeptical of documenting > things as if they really work for remote debugging. Thanks, that makes sense (though I would note that the documentation as it currently stands already implies that SVE and SME work for remote debugging). For the moment I would like to fix the QEMU gdbstub for the SVE + SME case, so that it at least reports the Z regs as having their actual maximum possible size (currently it reports them as having the max size for SVE only, even though it reports the 'vg' pseudoreg as being the SVE+SME current width). (That's this QEMU patch: https://lore.kernel.org/qemu-devel/20260202133353.2231685-3-peter.maydell@l= inaro.org/ ) thanks -- PMM