From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id x3eUJy42gWn39SQAWB0awg (envelope-from ) for ; Mon, 02 Feb 2026 18:41:34 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=MqPHzCF4; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9396C1E089; Mon, 02 Feb 2026 18:41:34 -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,FREEMAIL_FROM,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 6DDD81E089 for ; Mon, 02 Feb 2026 18:41:33 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id CAA594BB58DF for ; Mon, 2 Feb 2026 23:41:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CAA594BB58DF Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=MqPHzCF4 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id 4C3274BA5439 for ; Mon, 2 Feb 2026 23:41:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4C3274BA5439 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4C3274BA5439 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::331 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770075665; cv=none; b=sm6vvp8zDQ21XZo4lbeM/CMkuACwLirNSLE+RnOHqfxnwdrswpesFTJadNI7h3A55OFInEklveJngYoY+ZgJCs2+i1R3QVvSR5skvUQuq+DDz2MvGBTxuHYyT/S8jPrKFcjz52mHQ6+dJRkWCqrixyciDpLawZ445OSiyVNcDqI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770075665; c=relaxed/simple; bh=5wPxdx3Gx/l5R267zWYoZsz/9R92hEET4j37LnN6EzE=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=tWz5Ya6/TnU57SugU38MmZ9+SwVIMRS/sVq0P77yZIqd2e1boHXt20GN2b+h04a+bx+Z2rzd+GQRTjj2KYB6pRYgCVnofQNF7liMNuZ5N0xxszaQgD++KjY6RCJftvPMlEFtknRXZcYJDCQ5bJsKi+ePzVAFEPwYAfRGxuPdHRc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4C3274BA5439 Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4806e0f6b69so36731625e9.3 for ; Mon, 02 Feb 2026 15:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770075664; x=1770680464; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=be1xvT0vAVLEexK+pwYIJJkQuRhQGkF5Tl/Qn79RWww=; b=MqPHzCF4bnlT2tXu0tdgG9nfKM005NszaI3RWdi/E4ydHLAMDdQ3q8piR6cN6gSwXR H9x2nz8de1ggWLZt+lks4/CV0Yh5Ck90pPDnhIK2M4iCBoS7h6Ce2pKD/UPnj/6IB1tQ G2nHYCuNYHslpHKGmYepPTcNNYs34qE49kFO0DUiVGib6QAC/QAKacZQ2q306o7pQAte Vz+71LgLcs3cHb4DbWeAP5uP1ZH7ExFn/2MAu7QH7jZ+jn10hmzzBeRB3e3yOFdN1nDj 36ZXTZWu5v6rm7MJpYJ5FgtzLCMmhQZ+HKu7CJvd33cGv9yFCReaJJSppRMIvhOfS3x2 YnEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770075664; x=1770680464; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=be1xvT0vAVLEexK+pwYIJJkQuRhQGkF5Tl/Qn79RWww=; b=eQV+SxZa1SyAhwhHprDJHECStJsSI9/gzO9yTdkMZDEifbIRUsaUpLGzafqeuFI/WJ 3E2xKRUBcGihM8LoApT+U613C/8Ti5PWngig6hz+39UBxxcBcRjmjkXIpVj/21bUopp+ g8cYlXXP6VAr1vF9iYNaUQaefLKQxJi8WMvxFbHLolvR9MjS+GAvmbBAfzG5xXL3C1mf SJbI2RZjbTF5fbotANgMG20cS9JdyG+98pVgOSUAnb0Z8fCpXkO5c0UwNLMR85JS1vVN XGulyyVz6bWxP0ymXS3dA0m7rC7OwqU0GtqGE6WnLcLnPglAcfe/zAm8LR9LsY9GsAjQ t0JA== X-Gm-Message-State: AOJu0YwwelMUYmkksA24FgOHAMJtLXeukSdA63X42MqW41MfSL+DTFlG TowgjH48zum2UQSmi2F2JdxqnGJWoX+Vtb793b+gL25RXAVez3yJx2ft X-Gm-Gg: AZuq6aK3G3ALv/wMy/L0TFcEfjjrb7RXLxccuMt62StcltoJx7umti6Bc1038uIIudk xhUb4fl6f3wVGo/KxpYbaQYCOV99U+2i8wkbYQX9PSyKw0mG+P821X5oAF/y6iPeacjR2U4Vnzb hqvzapICgKGd+I246dHUTRru3noyKRoBX3ACdP5iRA83cPnF3eVpdtE4XYtSU+226NR2fof0gAm yxG+EQSrM1edrJh1LbNe27tN/+wtlbmOmOMB/qhS44cLsh7AzPf1iEDMNJ6LCYHCQfgeNDbsnZW iVf9zfGm0YHkgC5+Na9Q/QkoijSxOkFMohpYlW7mqru73n2dz+LHDcscTE9i1/F2u/SHncdVBoQ Pfhi5YBbJmducg7qWC3hGDBqLZvJhI0whfyAHIFI+QjofiW5MM/F8N0Eeq6R7u1qOGUlMfo4FJV c+0fkUHzvhcguAipg9w40KJ2Y= X-Received: by 2002:a05:600c:34c4:b0:480:52fd:d2e4 with SMTP id 5b1f17b1804b1-482db012dd7mr183573675e9.0.1770075663910; Mon, 02 Feb 2026 15:41:03 -0800 (PST) Received: from [192.168.0.38] ([86.12.216.189]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-482e266fbefsm101148015e9.14.2026.02.02.15.41.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Feb 2026 15:41:03 -0800 (PST) Message-ID: <57424b3d-a34e-4fbe-9858-d45b8dd49150@gmail.com> Date: Mon, 2 Feb 2026 23:41:02 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] docs: Clarify gdb remote protocol AArch64 SVE and SME handling To: Peter Maydell Cc: gdb-patches@sourceware.org, Thiago Jung Bauermann , Manos Pitsidianakis References: <20260129181122.1426596-1-peter.maydell@linaro.org> Content-Language: en-US From: Luis In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 Hi, On 30/01/2026 09:36, Peter Maydell wrote: > On Thu, 29 Jan 2026 at 23:18, Luis wrote: >> >> On Thu, Jan 29, 2026, 18:11 Peter Maydell wrote: >>> >>> The documentation of the AArch64 target features for the gdb remote >>> protocol has some areas where it is unclear about SVE and SME: >>> >>> * it doesn't say what to do if the target has only SME >>> >>> * it isn't clear about what the org.gnu.gdb.aarch64.sve vector >>> register size should be when both SME and SVE are present >>> >>> Clarify/correct the documentation: >>> >>> * org.gnu.gdb.aarch64.sve is effectively "the feature for the z >>> vector registers", and must be provided even when the target only >>> implements SME (because the z registers exist in an SME only CPU) >>> >>> * the z register size and the 'vg' pseudoregister in >>> org.gnu.gdb.aarch64.sve follow the architectural "effective SVE >>> vector length", which might be either the non-streaming SVE vector >>> length or the streaming SVE vector length >>> >>> Reviewed-by: Thiago Jung Bauermann >>> --- >>> gdb/doc/gdb.texinfo | 18 +++++++++++++++++- >>> 1 file changed, 17 insertions(+), 1 deletion(-) >>> >>> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo >>> index 80f49e21b7e..711a45435ef 100644 >>> --- a/gdb/doc/gdb.texinfo >>> +++ b/gdb/doc/gdb.texinfo >>> @@ -49742,7 +49742,8 @@ Extra registers are allowed in this feature, but they will not affect >>> @subsubsection AArch64 SVE registers feature >>> >>> The @samp{org.gnu.gdb.aarch64.sve} feature is optional. If present, >>> -it means the target supports the Scalable Vector Extension and must contain >>> +it means the target supports either the Scalable Vector Extension (SVE) or >>> +the Scalable Matrix Extension (SME) and must contain >>> the following registers: >>> >>> @itemize @minus >>> @@ -49780,6 +49781,14 @@ vector registers from the @samp{org.gnu.gdb.aarch64.fpu} feature. >>> The first 128 bits of the @samp{z} registers overlap the 128 bits of the >>> @samp{v} registers, so changing one will trigger a change to the other. >>> >>> +@samp{vg} represents the size of the @samp{z} registers, and is what >>> +the Arm architecture defines as the ``Effective SVE vector length''. That >>> +means that if the target implements SME and is in streaming vector mode, >>> +it is the streaming vector length. If the target implements only SME and >>> +not SVE, and is not in streaming vector mode, then @samp{vg} is 2 >>> +(indicating 128-bit vectors) and the @samp{z} registers match the @samp{v} >>> +FPU registers. >>> + >>> For the types of the @samp{z}, @samp{p} and @samp{ffr} registers, please >>> check the aarch64-sve.c file. No XML file is available for this feature >>> because it is dynamically generated based on the current vector length. >>> @@ -49793,6 +49802,9 @@ aarch64-sve.c file, and should match what is described in aarch64-fpu.xml. >>> Extra registers are allowed in this feature, but they will not affect >>> @value{GDBN}. >>> >>> +The @samp{org.gnu.gdb.aarch64.sve} feature is required when the target also >>> +reports support for the @samp{org.gnu.gdb.aarch64.sme} feature. >>> + >>> @subsubsection AArch64 Pointer Authentication registers feature >>> >>> The @samp{org.gnu.gdb.aarch64.pauth} optional feature was introduced so >>> @@ -49948,6 +49960,10 @@ extensions of the architecture. >>> Extra registers are allowed in this feature, but they will not affect >>> @value{GDBN}. >>> >>> +Note that a target with only SME but not SVE support must still >>> +provide the @samp{org.gnu.gdb.aarch64.sve} feature, to expose the >>> +@samp{z} vector registers. >>> + >>> The @samp{org.gnu.gdb.aarch64.sme} feature is required when the target also >>> reports support for the @samp{org.gnu.gdb.aarch64.sme2} feature. >>> >>> -- >>> 2.43.0 >> >> >> Thanks. The documentation update looks OK given the current needs, but I'm not too sure about keeping the SVE feature just for the Z registers. I find that a bit confusing. > > 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. It might not be a big issue for SVE itself, as we don´t usually change 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´d definitely like to make things work 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´d 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. Hopefully that made my position a bit more clear. > > thanks > -- PMM