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

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

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