Re: gdb support for SME-without-SVE ?

[Luis via Gdb <gdb@sourceware.org>]

On Tue, Jan 27, 2026, 21:24 Peter Maydell <peter.maydell@linaro.org> wrote:

> 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:
>

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
>