Re: [PATCH] docs: Clarify gdb remote protocol AArch64 SVE and SME handling

[Peter Maydell <peter.maydell@linaro.org>]

On Fri, 13 Feb 2026 at 11:39, Luis <luis.machado.foss@gmail.com> wrote:
>
> On 09/02/2026 09:36, Peter Maydell wrote:
> > On Mon, 2 Feb 2026 at 23:41, Luis <luis.machado.foss@gmail.com> 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