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

[Luis <luis.machado.foss@gmail.com>]

On 09/02/2026 09:36, Peter Maydell wrote:
> 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 ?
> 

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.

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

Yes, it does. And that's on me for not documenting it more clearly. We 
should use this opportunity to clarify things. If we take longer to fix 
the remote situation, we can update the documentation to make the 
situation clear.

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

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