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

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

[Peter Maydell]

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

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

[Luis]

[-- Attachment #1: Type: text/plain, Size: 4112 bytes --]

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.

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.

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.

>

[-- Attachment #2: Type: text/html, Size: 5138 bytes --]

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

[Peter Maydell]

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

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

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

thanks
-- PMM

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

[Eli Zaretskii]

> From: Peter Maydell <peter.maydell@linaro.org>
> Cc: Thiago Jung Bauermann <thiago.bauermann@linaro.org>,
>  Luis <luis.machado.foss@gmail.com>,
>  Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
> Date: Thu, 29 Jan 2026 18:11:21 +0000
> 
> 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(-)

Thanks.

> +@samp{vg} represents the size of the @samp{z} registers, and is what
> +the Arm architecture defines as the ``Effective SVE vector length''. That

I suggest to put the terminology you mention in @dfn instead of
quoting it.  It will be formatted as a quoted string in Info, but will
look much prettier in HTML and PDF formats.

Also, please leave two spaces between sentences, here and elsewhere in
the patch.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

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

[Luis]

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

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

[Peter Maydell]

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

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

[Luis]

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

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

[Peter Maydell]

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

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

[Peter Maydell]

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

Hi -- I just wanted to come back to this thread to ask how
the "native (ptrace) gdb SME-no-SVE" support is going. Do
we now have that landed, or at least solid enough that we are
happy to update the remote-protocol documentation?

thanks
-- PMM

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

[Thiago Jung Bauermann]

Hello,

Peter Maydell <peter.maydell@linaro.org> writes:

> On Mon, 2 Feb 2026 at 23:41, Luis <luis.machado.foss@gmail.com> wrote:
>>
>> 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:
>> >> 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.
>
> Hi -- I just wanted to come back to this thread to ask how
> the "native (ptrace) gdb SME-no-SVE" support is going. Do
> we now have that landed, or at least solid enough that we are
> happy to update the remote-protocol documentation?

I was about to submit the patches when I ran the full GDB testsuite
(I had been running a subset during development) and found a few
regressions I need to fix. I don't expect big changes though, and
I will submit the patches soon.

The essence of the changes is that if the target has SME but not SVE,
then GDB uses a target description with SVE but with vq = 1, meaning
that the SVE register set has the same size as the FPSIMD regset.

-- 
Thiago

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

[Peter Maydell]

On Fri, 20 Mar 2026 at 03:02, Thiago Jung Bauermann
<thiago.bauermann@linaro.org> wrote:
>
> Hello,
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Mon, 2 Feb 2026 at 23:41, Luis <luis.machado.foss@gmail.com> wrote:
> >>
> >> 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:
> >> >> 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.
> >
> > Hi -- I just wanted to come back to this thread to ask how
> > the "native (ptrace) gdb SME-no-SVE" support is going. Do
> > we now have that landed, or at least solid enough that we are
> > happy to update the remote-protocol documentation?
>
> I was about to submit the patches when I ran the full GDB testsuite
> (I had been running a subset during development) and found a few
> regressions I need to fix. I don't expect big changes though, and
> I will submit the patches soon.
>
> The essence of the changes is that if the target has SME but not SVE,
> then GDB uses a target description with SVE but with vq = 1, meaning
> that the SVE register set has the same size as the FPSIMD regset.

How does it see the actual vector registers, then ? Those will
have a larger size than vq=1, but there is no separate place
to report them, at least in the remote protocol...

-- PMM