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

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

Hi,


On 30/01/2026 09:36, Peter Maydell wrote:
> On Thu, 29 Jan 2026 at 23:18, Luis <luis.machado.foss@gmail.com> wrote:
>>
>> On Thu, Jan 29, 2026, 18:11 Peter Maydell <peter.maydell@linaro.org> wrote:
>>>
>>> The documentation of the AArch64 target features for the gdb remote
>>> protocol has some areas where it is unclear about SVE and SME:
>>>
>>>   * it doesn't say what to do if the target has only SME
>>>
>>>   * it isn't clear about what the org.gnu.gdb.aarch64.sve vector
>>>     register size should be when both SME and SVE are present
>>>
>>> Clarify/correct the documentation:
>>>
>>>   * org.gnu.gdb.aarch64.sve is effectively "the feature for the z
>>>     vector registers", and must be provided even when the target only
>>>     implements SME (because the z registers exist in an SME only CPU)
>>>
>>>   * the z register size and the 'vg' pseudoregister in
>>>     org.gnu.gdb.aarch64.sve follow the architectural "effective SVE
>>>     vector length", which might be either the non-streaming SVE vector
>>>     length or the streaming SVE vector length
>>>
>>> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
>>> ---
>>>   gdb/doc/gdb.texinfo | 18 +++++++++++++++++-
>>>   1 file changed, 17 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
>>> index 80f49e21b7e..711a45435ef 100644
>>> --- a/gdb/doc/gdb.texinfo
>>> +++ b/gdb/doc/gdb.texinfo
>>> @@ -49742,7 +49742,8 @@ Extra registers are allowed in this feature, but they will not affect
>>>   @subsubsection AArch64 SVE registers feature
>>>
>>>   The @samp{org.gnu.gdb.aarch64.sve} feature is optional.  If present,
>>> -it means the target supports the Scalable Vector Extension and must contain
>>> +it means the target supports either the Scalable Vector Extension (SVE) or
>>> +the Scalable Matrix Extension (SME) and must contain
>>>   the following registers:
>>>
>>>   @itemize @minus
>>> @@ -49780,6 +49781,14 @@ vector registers from the @samp{org.gnu.gdb.aarch64.fpu} feature.
>>>   The first 128 bits of the @samp{z} registers overlap the 128 bits of the
>>>   @samp{v} registers, so changing one will trigger a change to the other.
>>>
>>> +@samp{vg} represents the size of the @samp{z} registers, and is what
>>> +the Arm architecture defines as the ``Effective SVE vector length''. That
>>> +means that if the target implements SME and is in streaming vector mode,
>>> +it is the streaming vector length. If the target implements only SME and
>>> +not SVE, and is not in streaming vector mode, then @samp{vg} is 2
>>> +(indicating 128-bit vectors) and the @samp{z} registers match the @samp{v}
>>> +FPU registers.
>>> +
>>>   For the types of the @samp{z}, @samp{p} and @samp{ffr} registers, please
>>>   check the aarch64-sve.c file.  No XML file is available for this feature
>>>   because it is dynamically generated based on the current vector length.
>>> @@ -49793,6 +49802,9 @@ aarch64-sve.c file, and should match what is described in aarch64-fpu.xml.
>>>   Extra registers are allowed in this feature, but they will not affect
>>>   @value{GDBN}.
>>>
>>> +The @samp{org.gnu.gdb.aarch64.sve} feature is required when the target also
>>> +reports support for the @samp{org.gnu.gdb.aarch64.sme} feature.
>>> +
>>>   @subsubsection AArch64 Pointer Authentication registers feature
>>>
>>>   The @samp{org.gnu.gdb.aarch64.pauth} optional feature was introduced so
>>> @@ -49948,6 +49960,10 @@ extensions of the architecture.
>>>   Extra registers are allowed in this feature, but they will not affect
>>>   @value{GDBN}.
>>>
>>> +Note that a target with only SME but not SVE support must still
>>> +provide the @samp{org.gnu.gdb.aarch64.sve} feature, to expose the
>>> +@samp{z} vector registers.
>>> +
>>>   The @samp{org.gnu.gdb.aarch64.sme} feature is required when the target also
>>>   reports support for the @samp{org.gnu.gdb.aarch64.sme2} feature.
>>>
>>> --
>>> 2.43.0
>>
>>
>> Thanks. The documentation update looks OK given the current needs, but I'm not too sure about keeping the SVE feature just for the Z registers. I find that a bit confusing.
> 
> 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.

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.

Hopefully that made my position a bit more clear.

> 
> thanks
> -- PMM