From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id /fm2LxIWj2moPzkAWB0awg (envelope-from ) for ; Fri, 13 Feb 2026 07:16:18 -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=vyEBIRox; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id ADB5E1E089; Fri, 13 Feb 2026 07:16:18 -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 7E27F1E089 for ; Fri, 13 Feb 2026 07:16:17 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 604A04B9DB66 for ; Fri, 13 Feb 2026 12:16:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 604A04B9DB66 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=vyEBIRox Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) by sourceware.org (Postfix) with ESMTPS id 512304BA23D7 for ; Fri, 13 Feb 2026 12:15:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 512304BA23D7 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 512304BA23D7 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2607:f8b0:4864:20::1134 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1770984949; cv=pass; b=h3s9MsXbf9FhUjJleLUQ68ksKiOtYZ6ztelfJIkgv+Ub6uL+D9NcYRHKvntJVYnDuOX9sNoGcDhSFO7LOHYQNRVU2XiQItI+YxACdZFtRfjAitKvwKYSpYCDrS59wHt5Ok2qKlAhOfg9FyHXlgjmCxe/a5PR3G3AVAS2uQZ1lGQ= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1770984949; c=relaxed/simple; bh=4q7OFTdOb2Zkql+XXa1bzWKdd6eWJX/ZJJozSpD89mw=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=PFy9bmecFfHhQeEKF5HDn0P3hMi91+vElhNVGzn4Fg7Umfv2eYe+XrVP597I669uBEDilzHYhlE6UUTTrIpWjRXWjK+kIcUJ1Z2nr0zLTsc0ADC6yvTq0Pygj6WbjjmF9O2lC+Fu7xFU9sVdupqv+Hch2sJpo76Iudnq1Wp6ax0= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 512304BA23D7 Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-7950afac0ffso28801667b3.1 for ; Fri, 13 Feb 2026 04:15:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770984949; cv=none; d=google.com; s=arc-20240605; b=Qy6d/KEkc/81OAS8iftI+Be4y9lr1/pDPZYFGFn6A9qZd4/jwZm4l00uc7dHUhY1Db xP0blLZNYFCLchVAkTMr0/jfHZvi+M60Mv/mKC1Sas6JieJOJ4TPwd7SxEEtsrx3O9Gc GOL6zRy7x7V/fpcV54K71HPYai8yxSw3e6I3C76JgjSkGfIvTtR+VeHDcSaBnyqlmEBL KLFV5HDtZPeXzvxajt+c6LV8H0Ya/2NoGs4hkERqOCgoB3TfsWv2CiSxqZMefmkXhwPw Vp7L5pyfNP/5PWLtizA+YXFw8jClExA2HGaPFYkUsXFpfNMnrzif/1vOeqnvdG53of5I f8LQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=UvgfjNffc1Q318Vs9AZOh/fi31h10wj/HTxB816cjCA=; fh=IbnlJmMARMsicHKe8AhDmIyoH4xi04g8H/HrmWB6vJA=; b=U9ka8LMLvAGyrN36wGKKKAsc5PwCcehhiq9XSRjAYXYvpyr1OuYxMxwmTWkw0z/wfD GDX+PcB+zvK3fIjywRF08zrLb84LtmRhvqLRTI5GZ9wseTQGwwr+bz7vj6BSAcRxx1KU v4pYjhzCh5eZSRzsChBjjEvh1PesftWak+Pgo2bz82xTnbNRLoHPL8S27NLeDNFD0nVI 6yUHTY0xtHCWqwC95I+8yhJIuXP//tIFix0jWpUuATrEqxbrLzhaBfeoOf7tGZ02LRFa cZEdI3uIWx18YS0TutZvIv6zlG9IS3O+/y/VRmByDuTtq5lrXdC+NvR0RZvrLBliTN0L X/xg==; 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=1770984949; x=1771589749; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UvgfjNffc1Q318Vs9AZOh/fi31h10wj/HTxB816cjCA=; b=vyEBIRox6aLpwlLcJlBYt/U5iZk1IcyTCg+Ni2NyGpbRVlt4yjTxonc3ALtrEH/HvN 00jCDP4IwLcL9YFR/hg7/b6nCq8nmJd0/lo3ODvky1u4BlRF6c6pfeipP4DG+f0YumXC rXzeQ0W/pfIWBMyrPr5SLeXsHs8B4y007Oz5V+t9e2ijtlBp3pFiJPns2oGpj8Xaa7YY CoPRIrBpSLdh9hJwjRZB5U/vvioZA1KCETKWhzzAdqBQ2z9B/cc+Lzvub8MVZMrPRO3z N5Guvo+a1d2LaimfvtyyXhhVHfl/3af1vS+nc8TNx5vNyoear7mHqgtIe3/XbUbh1uV+ Y3LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770984949; x=1771589749; h=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=UvgfjNffc1Q318Vs9AZOh/fi31h10wj/HTxB816cjCA=; b=UUwrLOU/C8N4ZmXceEGNZj0YmIMVyFU+je8PUhVe8bFrc8T78+TzQW/1sJvoNjGg48 MQt55aUSv4S9s/5lQ/bzt0zX/vWb7/3H8li9NPiioFwHNX+GOPVYLWyANx8HPm3X7moO c9b4GlHXX1pj7cLwAmZUHFaVXjxLOka205/eAuPIhBobfh3kqSVzqQM+7nwFqLLoaZpY 81ATmzB+J8wHuLVgfp8kM1Q0z2vbTFRlz/Ztw9vVy8m5MSbV1YrpOQMbfJ75SnW+2Igy bfKSfV6RGvf9heuy5s8+ipH4btVrbvTgNOIShNRtMG8ZOvcWKWLjKigcvS8qBrJGVH7H bUiw== X-Gm-Message-State: AOJu0YzKhysBkURSp8x+U9IOHHFLy4vwgEA7GaYHB1Q4fWZfqj134rmR EfF1TAjBPZ+NuJS0fduqZYMVI5R91M+QoRuvfkZhiDuE+1QPls5HQ27vt7eusYoVtOcmIlbo1il B9HMKHfDS8qJMimWStOZaIf7KX+GrrNzHyR/4UQLQFg== X-Gm-Gg: AZuq6aK79UfIkXfj4wlxHKDxm+vG8rduk578kl2vPrRBw7V4I1bGyS1EbE/QAGW9BBM po3bYjvVZNC86uB/xSkLx9+qN60MnEMhC+eNrDY291K1Dob50HKvXOHKSZYkWIWoIyhlwdgBb4Z pw0l55OhQlkBZBHsPKsZTY0rHI+VfRTelcjROF9NCFdzmLzLlOKRWhPPEI59cCmtBZw+UINwaol OfLsCQZzhAe5u5QqpBO5Xam3ltD+r1rFiDXb1gaBB9SFgbQ5fjBjKWTTgoi7iPw3tkev51e8QaW L8o4DAsmVLPl/D+Fs28L06wyGfUJyPzOMhqw1rW37WvrDMRszCjffXH7yvW1my8wJ9o= X-Received: by 2002:a05:690e:1441:b0:64a:d3b2:d394 with SMTP id 956f58d0204a3-64c1960e455mr1031191d50.26.1770984948579; Fri, 13 Feb 2026 04:15:48 -0800 (PST) MIME-Version: 1.0 References: <20260129181122.1426596-1-peter.maydell@linaro.org> <57424b3d-a34e-4fbe-9858-d45b8dd49150@gmail.com> <3624e27d-52f6-4523-b9e4-f41f6ca48548@gmail.com> In-Reply-To: <3624e27d-52f6-4523-b9e4-f41f6ca48548@gmail.com> From: Peter Maydell Date: Fri, 13 Feb 2026 12:15:36 +0000 X-Gm-Features: AZwV_QiZqXO6LQ0AS1abftRn2meAr2C_pxXimsRc6nNwLJbhtVosobXFXqG9cbI 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" 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 Fri, 13 Feb 2026 at 11:39, Luis wrote: > > On 09/02/2026 09:36, Peter Maydell wrote: > > On Mon, 2 Feb 2026 at 23:41, Luis wrote: > >> 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 ? > > > > The problem is the register buffer size changes according to the vg > size. If we let the program run on the remote and it eventually changes > vg, the next time it stops the remote will report a block of registers > with a size gdb is not expecting. So this is the problematic case. At least in QEMU's implementation, it doesn't, though: the register data type reported by the stub is fixed to the worst-case Z reg size: we generate the XML for the target up-front and there's no mechanism for changing it dynamically later. I assumed this was why there's a separate 'vg' pseudoreg, so gdb knows how to interpret the data in there and that the tail end of it might be junk/to be ignored. > > 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). > > What gdb expects is the remote reporting Z registers that match the > actual size based on vg (no streaming mode) or svg (streaming mode). > > By maximum size, do you mean QEMU always reports whatever maximum we > have between vg/svg? Current QEMU behaviour (some of which I think is bugs on our side) is: * the Z regs in the SVE feature XML have the width of the worst-case possible SVE vector size for this CPU (even if SME vectors are bigger) * the predicate regs in the SVE feature similarly are based on worst possible SVE vector size * the vq pseudoreg in the sve feature reports the current effective vector length (i.e. SVE VL when in non-streaming mode, SME VL when in streaming mode) * the SME ZA array in the XML is sized for the worst-case possible SME vector size * the SME svg pseudoreg reports the SME streaming VL when in streaming mode, and reads as zero when not in streaming mode The QEMU patch I linked to earlier changes the first two of these (Z and predicate reg size) to "width of the worst case possible SVE or SME vector size" (so it lines up with our interpretation of the meaning of the "vq" pseudoreg, and allows the debugger to see the whole of a Z reg in streaming SVE mode, and doesn't make gdb crash if there's no SVE and we claim the Z regs to have 0 size). thanks -- PMM