Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb <gdb@sourceware.org>]

On Tue, 27 Jan 2026 at 11:31, Peter Maydell <peter.maydell@linaro.org> 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:

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?

(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.)

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