From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id itNjFpJheWlQBhkAWB0awg (envelope-from ) for ; Tue, 27 Jan 2026 20:08:34 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=DttT16nj; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4B3911E0DD; Tue, 27 Jan 2026 20:08: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,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 852831E089 for ; Tue, 27 Jan 2026 20:08:33 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id EF3E04BA2E39 for ; Wed, 28 Jan 2026 01:08:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EF3E04BA2E39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1769562513; bh=UXGDkQcZxjeOyVJMaASxfIxx+jQNLkLwlR/AtNEC6N0=; h=References:In-Reply-To:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=DttT16njDqfddW2P4n3nZDSZh3GsjYRcGo5CZlDL5GISPeZ5RQB6NsP0RHnK2ikDp n+B4EoAiPnKxVRcp7YVDTr1e0Hw9RijOivT3mNqH7Opx0Xptk6L4/jy3A+luD7fzyJ xtb99dIdSNPUH2prSQUvz7LFhb+rd/n8+mz7BlGI= Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by sourceware.org (Postfix) with ESMTPS id 232F34BA2E1F for ; Wed, 28 Jan 2026 01:07:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 232F34BA2E1F ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 232F34BA2E1F ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1769562476; cv=pass; b=genYQLvK332Fq3RhIHUTBDrdO938HIRbBCsBRhSe82pE48HnI7DKnfIvPdJlXbRa8DcUTSQ6PkYJUr+C3CSNNhgv5UeG1GcX4w8j8kU6SHp3t1ZaTII3eN4pqg4eoRhhw8Jo3cDgAogUIlRLdasnOIqYbqLNbWqzesVh/AKfiAo= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1769562476; c=relaxed/simple; bh=/yliykND3jZ/HZtF9Yfq2KL0bDj8KZAq00oiBllX3TU=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=FmjEBbDgErCT65pi96FsR/FgqPe2Q1N038vEBZSRCB1PdH0PWSluVBjCjYFxn4oQrkXJNa0fIfkezHYShWJ5xGWEYyIkJMenf4uh9ezsmlWGBw0wwI57xzAMSIuOeAP/uZ2AORiSEnlKf86yUNHFOaZYlVwt0/Thq6UIdj+YSBw= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 232F34BA2E1F Received: by mail-oi1-x22e.google.com with SMTP id 5614622812f47-45c962424daso1861731b6e.2 for ; Tue, 27 Jan 2026 17:07:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769562475; cv=none; d=google.com; s=arc-20240605; b=fxoWsQ/S1+a0+umK0bWr2rzaV820l8Rg/GTDLI+8rDf677ZMLcP5dIn/kLLctLlbyO +Vi7olvO/qLbYVr4FrLyTcxNMwzp/NIlkag8TAUxagV+q/8+VoYx1zv/TyXCvcEdvFgv cWvIX3bVvQqDLjiqknXZJ6iYMDOQ/X+MgsZjeCfP2mAdBDt7v1BQ3dPZC3k9qe6JPKOZ c6A3CFCgr5OCSFIDirCt6H2ARr3C/HugIFFBBf0XCAGU2muGgDaBmCeeMNjOn2/Y/0Kc h1zBThTo/relxg9oIJqlhck2wl0tLeu3sNtG721zCyNezqOVj/yfEO9JlRGjHVALL8dg IAJg== 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=6BZuFkUbEY/Yo68AUyeE7UUjRlMgZ3dQDG8Tkn8Mzrw=; fh=r6VEqF8KKNpiQxetizRq8yKYCY8v+fX8aZaT2IL2Dws=; b=P9DKJTRcH0ZfL8qbOrlCVjk7w1QvLOa+nAr+X0jn7nEjfpEHSy0CN1dLBIAt9BmcxG jWkxWyhINdO+753gWdh+Xqz7YOo5pqkUgI1/ll/89lhUM2qv+g6/ezf+QIQshwldeUsg CU3p1yit2VS1yP1KpRmV4Ne9+1g6YEA3ey0eppNlg0MQgeoq6qRCu01zk3krSFcbn87v jTbp0qaj08qCGC0M9jqwDUHPW5dagI7OwdAEF7bTtjz7LhqKil3OGRX9I5iR44GpG+jR FFEQflRbMqkSrRw7V+HvWu3c52CKULdGcCL131xNhq8Lwx0VhjeU6KbcVcv2htUn6g32 tcZw==; darn=sourceware.org ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769562475; x=1770167275; 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=6BZuFkUbEY/Yo68AUyeE7UUjRlMgZ3dQDG8Tkn8Mzrw=; b=b6/r61p2KzmA0cKeC5FIuS224d0X7tt0oB/bPmvfcgy3IiMgFjqmIy1NVV8H2M6l3c pRy3sOtGkoOlPNw7QlaoEvPy/h4Jgi2Y0gTi6UbxbWoABhgriKjPj+CjWv/BKwOEbyAh wb38Iz5yJy5Esi+7RMnBwQpAb2RIdn3Rv8dbh7LDgjAzR5ZEB3Q07qTxBBJW8dSjAGWq BY3/d7QDNBlwSnnez1tIJgk3RxJ3AYfHOI/QnPYFe0ClRPSu0qFtMbXHJGYE/jB3eAIQ iydAPOeoi3+WCRuRW3eBqDR2pyenDwJE0zslgKgDvIrvnVjl57y1qjcYrOa38NVRaIxD EuKg== X-Gm-Message-State: AOJu0YzmL6rYJPWolaWA68Mc5uGnpMent3FCxrmAuaYzpv14/LwtSlcS fq/Do16CaDGkvM3AeGrITNoaMgkxqEQVOQhyYKlU+Kw5z/anpZ0smFNQ0u6UWE7DTSLRriZR7Fu wgdFCOuPLNSwm8UzB+96cRQVqNsNAZuuSrA== X-Gm-Gg: AZuq6aIKqouSf08lN+a/nWaaK7OCJcWfIyBmL7LKyt4jc9Qe0m2imoGtgfBStmRMBTE T3quNVO7IcVjQywVzroRnocaY5nTtyvLpHArO4EpDWgAxunkUvkjUhR3NwXzBt0XYv62LPPhFx3 wAMYMCUNrBy51szSYfu7xkh/9gViEI0I7isrEGiB0t1bMKTyY/nOMRSkCVxA0HgT5+ES63j1Gzx xD4kpPMK1xFub1ADzZpU+K2LCuve2RqHRdnRal7a/n5336uFjv90YIf0oZZPLgfxnkl6pY= X-Received: by 2002:a05:6808:1506:b0:450:d28e:2509 with SMTP id 5614622812f47-45efc6b60d5mr2191497b6e.66.1769562475297; Tue, 27 Jan 2026 17:07:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 28 Jan 2026 01:07:43 +0000 X-Gm-Features: AZwV_QjiYYMDVNgQHT_T1XtJtkv7S_u82zAYGx7y_G3_h6GE6ypAU9NdtEuxAg0 Message-ID: Subject: Re: gdb support for SME-without-SVE ? To: Peter Maydell Cc: gdb@sourceware.org, Manos Pitsidianakis , Thiago Bauermann Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.30 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Luis via Gdb Reply-To: Luis Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On Tue, Jan 27, 2026, 21:24 Peter Maydell wrote: > On Tue, 27 Jan 2026 at 11:31, Peter Maydell > wrote: > > > > Hi: is GDB for Arm intended to support configurations where the target > > CPU has SME but not SVE? > > > > We're just implementing support for that in QEMU for using SME > > with the hvf hypervisor accelerator on macos systems, but when > > we tried connecting gdb to QEMU gdb crashed: > > > > (gdb) target remote localhost:1234 > > Remote debugging using localhost:1234 > > ../../gdb/aarch64-tdep.c:3068: internal-error: > > aarch64_pseudo_register_type: bad register number 160 > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > Fatal signal: Abort trap: 6 > > > > > https://lore.kernel.org/qemu-devel/CAAjaMXZLG2aBtStRhyvmdENj1Z+Mx05BmDgyYUoYrc_ZnHwyVQ@mail.gmail.com/ > > > > Is this a known missing feature in GDB, or is it a config that's > > supposed to work but we've got the XML register description wrong > > somehow? > > Further investigation shows that this happened because QEMU was > accidentally reporting the zN vector registers with a width of > zero. Does gdb consider "internal error when fed bogus XML" a > bug, or just a "don't do that then" situation ? (Obviously we're > going to fix QEMU to not do that ;-)) > > Aside from that, I do have some questions about the GDB > remote protocol SVE and SME features where the docs at > > https://sourceware.org/gdb/current/onlinedocs/gdb.html/AArch64-Features.html > are not clear to me, and I hope you can clear up my confusion. > > (1) In a CPU with both SVE and SME, what does GDB expect > org.gnu.gdb.aarch64.sve "vg" to be reported as -- the SVE > vector granule, or the current vector granule taking account > of both SVE and SME? The docs can be read to support both: > vg is for SVE and svg is for SME and SSVE. When in streaming mode the Z registers will use svg instead of vg. > https://sourceware.org/gdb/current/onlinedocs/gdb.html/AArch64.html > says both that vl/vq/vg "define the size of each Z register" > (implying it's the current vector length which might be the SVE > vector length or the streaming vector length depending on SVCR.SM) > but also "When streaming mode is enabled, the program supports > execution of SVE2 instructions and the SVE registers will have vector > length svl. When streaming mode is disabled, the SVE registers have > vector length vl", implying that vl/vq/vg are purely the SVE > vector length and that to get the actual size of the Z register > gdb will look at both vq and svq and SVCR.SM. > > (2) If the CPU has SME and not SVE, presumably we should still > expose org.gnu.gdb.aarch64.sve, as it's where the z registers are. > What should we report "vl" as here? How about when the CPU is not > in streaming mode and the z regs aren't accessible? > Are there still Z registers without SVE? I don't think this is properly supported in any case. On top of that SVE and SME are not properly supported via the remote protocol. In theory it works if you don't change vg/svg mid-execution. So no SSVE enabling etc. But in practice it does not work well. When the vg/svg size changes you end up with overruns or garbage. The initial implementation of SVE assumed remote debugging wasn't important. We're stuck with that until remote protocol enhancements are contributed. Those enhancements have been proposed multiple times but there were always downsides and it tends to die and fall into limbo. It mostly only affects SVE and SME. Maybe AMX. > (3) What does GDB mean when it says about the vector registers > z0..z31 in org.gnu.gdb.aarch64.sve that "Their sizes are variable"? > As far as I know once the gdbstub has handed you the XML that > fixes the size of the registers in it and they can't change > afterwards. Does this bit of the docs just mean "the stub > will give gdb a register that might be any size" ? Or is gdb > going to expect to transfer more or less data when it does a > register read/write based on the current value of vg ? > (Currently QEMU assumes that it will always get/send enough > data to completely fill the worst-case maximum vector reg > size it defined in the XML.) > Technically that is not how it should work. For SVE and SME we would expect the register data to match the current size of vg/svg. But like I said above, this does not even work for remote protocol SVE and SME until that restriction of a single XML per debugging session is lifted. Native gdb uses per-thread XML descriptions. That is why it manages to toggle the sizes of SVE and SME registers. Remote stubs use a single XML. Hopefully that provided some clarity. > My guesses as to plausible answers are: > - for an SME-without-SVE CPU, the stub should still report > org.gnu.gdb.aarch64.sve as well as org.gnu.gdb.aarch64.sme. > > - org.gnu.gdb.aarch64.sve 'vg' should be the current length > of the vector registers (accounting for both SVE and SME), > and 2 when the vector registers aren't accessible (128 bits, > per the Arm ARM rule R_KXKNK). > > - the z regs are variable size in the protocol only in the > sense that the stub gets to set the size when it sends the > XML, and it sizes them to MAX(sve_max_len, sme_max_len). > Register read and write packets then always send and > receive that many bytes, even if the current runtime > vector length is smaller and the tail of the vector is > inaccessible junk. > > thanks > -- PMM >