From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 9z3pMZ0Nj2neNjkAWB0awg (envelope-from ) for ; Fri, 13 Feb 2026 06:40:13 -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=CKO5b4LD; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id AAFE91E0BA; Fri, 13 Feb 2026 06:40:13 -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 A28701E089 for ; Fri, 13 Feb 2026 06:40:12 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 14BD94B9DB74 for ; Fri, 13 Feb 2026 11:40:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 14BD94B9DB74 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=CKO5b4LD Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 623D04B9DB74 for ; Fri, 13 Feb 2026 11:39:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 623D04B9DB74 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 623D04B9DB74 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::52d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770982784; cv=none; b=ZyAoecDPvBW1efCXtFPiZS7JUdoV1CRSTejydkEv8wA/JID8bWgWnocxDDYo+1pPyO1K7VZMVi5SbPT6RpLEpVxJ1mCGIkZATKQUBKPPXQ7tyitS34nkF0Vq3Ea7PobFqGGgAfIWerEqoWmOu2cKUtmvEm0VIAfaRJb4+1jBt8I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770982784; c=relaxed/simple; bh=fC+k5MhWnRgz2HC3u6NQKG//mjioeqaA3vKrTdagOvU=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=MP960cgZsuyWr/uTEn9YhmHcrtoUi52uchrBf0qNsbELZvOydhvlpWto1nPhom96T2JU607VW5PTbWvvAMp+ObWzOQ6I9HGjk54xUOKqhNnNkStaQCJV3dsZBO8dqAEeJ1WXv4cfBWQwQP902SkpgtvmM5b8UdDd/WX4mXdyFFI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 623D04B9DB74 Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-65a3fdeb7d9so1284013a12.0 for ; Fri, 13 Feb 2026 03:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770982783; x=1771587583; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vlgXOeDlXRbKH7iBXuG+8/K3y7pYwvEUmzIV9VOBrZk=; b=CKO5b4LDja3Cqsi/WnQ3lL9WAjS5ZIPRFXkMIRGV+eE4jVfrpGUHtobSjyQ8o/xwJG hiqAxNE03pwR79zGZ1Kam0CiQYt/jmj6Wvx5+mZblcwgMW2wiUDOerSYuHr+m0yYqr0S ECUoRpYPEkFDxSkGf9d2dZ9BVULvw2FuGrpTq0Q9aTkCeEINHpAhDI0+GCVGkdi+XXqM LDcKOLVoOi864jyjIWxHfm03S16OsiQa+jdRCiP5MpM+wfvIeeHsFYpMjq67vWODkWRl tkx2SEsLiGMwboUS8qa8YErTTlj9QiroBLIPSzmDC0XiEshrf+KlIPsE0zgy0MW6ihfY iBKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770982783; x=1771587583; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language: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=vlgXOeDlXRbKH7iBXuG+8/K3y7pYwvEUmzIV9VOBrZk=; b=kmknjDev2URnUiLqM5k3PtFRC9M/DTwwxJhMZNDys/ZE5gTFMLeBAfhjIp62FBonxa UshKLfqv/ZxJfMGt1cD8qx9pt66PWEzo6Ut0BvnU+Iz0kXUKgSeBmwZD12cJ+8al46zk ijH9FTo76+0eVUao2HOU4snN4evyGoSWPKmFrT0KLAgFgjE1K7I3AU2+QdWc2GJIraNL lrqkxpvXMHKgBmnRHn5oPNio0LdU4ls2/vNwLVhZvWIUlGD+T+lV4Rq307QBXNyOp1N4 An4dAPpSRXBXs+WfYG16F96el7uZKCekc22xBS6IfIPEYgxexX+6I8wzi6O7j/23Ujvm qkoQ== X-Gm-Message-State: AOJu0Yy6BGXSubX4e6rh6G1x8U8EdJuDmO9BS1hw8UqwJSzU/DB26gy5 8GjU7zDKto7ScNHS34XjQiYGaA8bwCfEvl1/qFlkAEpsyDl0P0eAcC8a X-Gm-Gg: AZuq6aLt563vpUrb41QbLkvJDCBXfLH8pmX3sxNRvyewTHfcGe47Yp2cW7wCeqq/+gC LES323q+48YVjd4MB81tLtObCbxS4TKMiiTQNXWhZnQ6lKmDeRumlx/8xzCT3HFaFJN8zAHYX29 wn5JnMW4IqdAxk7S2SbQVhjryHoANx1GmHxr7t2JTnNM2oe6/sbcjCEQB3/Gz1oB6KNzROUr+u5 Rmz+8H3MdYLBBxlOb70rpA5uZNLcjHR+3aoKYLteKE1CHmvfxlbh7JzEvEAVk9cZdTqY3EZuemB LP/QbHjkRnr77KbjYjmPe9aiulumEuWES+H7BkezFWrSgeIn5B6BQ9sDj/Tgdr8EcZS8ldNRe9J 83uZKcl2pkiQmNTP6NsY0K1g0+R0gi5Htf0+wKryShqT6KpR3WNF1c1aN6Tqe3G0gQLGQNuUDIB De7JWTJyt7gJdKkW18URbegBHrxKi8abszUn4= X-Received: by 2002:a05:6402:398c:b0:659:3ed2:13ec with SMTP id 4fb4d7f45d1cf-65bb10fa5d6mr540588a12.2.1770982782909; Fri, 13 Feb 2026 03:39:42 -0800 (PST) Received: from [192.168.0.38] ([86.12.216.189]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-65bad4fa7c7sm576427a12.31.2026.02.13.03.39.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Feb 2026 03:39:42 -0800 (PST) Message-ID: <3624e27d-52f6-4523-b9e4-f41f6ca48548@gmail.com> Date: Fri, 13 Feb 2026 11:39:40 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] docs: Clarify gdb remote protocol AArch64 SVE and SME handling Content-Language: en-US To: Peter Maydell Cc: gdb-patches@sourceware.org, Thiago Jung Bauermann , Manos Pitsidianakis References: <20260129181122.1426596-1-peter.maydell@linaro.org> <57424b3d-a34e-4fbe-9858-d45b8dd49150@gmail.com> 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 On 09/02/2026 09:36, Peter Maydell wrote: > 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 ? > 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. >> 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. > > 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). > Yes, it does. And that's on me for not documenting it more clearly. We should use this opportunity to clarify things. If we take longer to fix the remote situation, we can update the documentation to make the situation clear. > 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? > > (That's this QEMU patch: > https://lore.kernel.org/qemu-devel/20260202133353.2231685-3-peter.maydell@linaro.org/ > ) > > thanks > -- PMM