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

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

On Mon, 2 Feb 2026 at 23:41, Luis <luis.machado.foss@gmail.com> 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 ?

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

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

(That's this QEMU patch:
https://lore.kernel.org/qemu-devel/20260202133353.2231685-3-peter.maydell@linaro.org/
)

thanks
-- PMM