gdb support for SME-without-SVE ?

gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

Hi: is GDB for Arm intended to support configurations where the target
CPU has SME but not SVE?

We're just implementing support for that in QEMU for using SME
with the hvf hypervisor accelerator on macos systems, but when
we tried connecting gdb to QEMU gdb crashed:

  (gdb) target remote localhost:1234
  Remote debugging using localhost:1234
  ../../gdb/aarch64-tdep.c:3068: internal-error:
aarch64_pseudo_register_type: bad register number 160
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  Fatal signal: Abort trap: 6

https://lore.kernel.org/qemu-devel/CAAjaMXZLG2aBtStRhyvmdENj1Z+Mx05BmDgyYUoYrc_ZnHwyVQ@mail.gmail.com/

Is this a known missing feature in GDB, or is it a config that's
supposed to work but we've got the XML register description wrong
somehow?

It looks from the aarch64-tdep.c code like perhaps GDB assumes
that the Vn vector registers only exist with SVE, but they also
exist in SME-only CPUs.

thanks
-- PMM

Re: gdb support for SME-without-SVE ?

[Simon Marchi via Gdb]

On 2026-01-27 06:31, Peter Maydell via Gdb wrote:
> Hi: is GDB for Arm intended to support configurations where the target
> CPU has SME but not SVE?
> 
> We're just implementing support for that in QEMU for using SME
> with the hvf hypervisor accelerator on macos systems, but when
> we tried connecting gdb to QEMU gdb crashed:
> 
>   (gdb) target remote localhost:1234
>   Remote debugging using localhost:1234
>   ../../gdb/aarch64-tdep.c:3068: internal-error:
> aarch64_pseudo_register_type: bad register number 160
>   A problem internal to GDB has been detected,
>   further debugging may prove unreliable.
>   Fatal signal: Abort trap: 6
> 
> https://lore.kernel.org/qemu-devel/CAAjaMXZLG2aBtStRhyvmdENj1Z+Mx05BmDgyYUoYrc_ZnHwyVQ@mail.gmail.com/
> 
> Is this a known missing feature in GDB, or is it a config that's
> supposed to work but we've got the XML register description wrong
> somehow?
> 
> It looks from the aarch64-tdep.c code like perhaps GDB assumes
> that the Vn vector registers only exist with SVE, but they also
> exist in SME-only CPUs.

Not an ARM expert, but from what I read, SME builds on top of SVE, so I
would guess that having SME implies having SVE.  For instance, from [1]:

  Arm Scalable Matrix Extension (SME) is an architecture extension that
  provides enhanced support for matrix operations. SME builds on the
  Scalable Vector Extensions (SVE and SVE2), adding new capabilities to
  efficiently process matrices. Key features include...

Simon

[1] https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-scalable-matrix-extension-introduction

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Tue, 27 Jan 2026 at 14:21, Simon Marchi <simark@simark.ca> wrote:
>
>
>
> On 2026-01-27 06:31, Peter Maydell via Gdb wrote:
> > Hi: is GDB for Arm intended to support configurations where the target
> > CPU has SME but not SVE?
> >
> > We're just implementing support for that in QEMU for using SME
> > with the hvf hypervisor accelerator on macos systems, but when
> > we tried connecting gdb to QEMU gdb crashed:
> >
> >   (gdb) target remote localhost:1234
> >   Remote debugging using localhost:1234
> >   ../../gdb/aarch64-tdep.c:3068: internal-error:
> > aarch64_pseudo_register_type: bad register number 160
> >   A problem internal to GDB has been detected,
> >   further debugging may prove unreliable.
> >   Fatal signal: Abort trap: 6
> >
> > https://lore.kernel.org/qemu-devel/CAAjaMXZLG2aBtStRhyvmdENj1Z+Mx05BmDgyYUoYrc_ZnHwyVQ@mail.gmail.com/
> >
> > Is this a known missing feature in GDB, or is it a config that's
> > supposed to work but we've got the XML register description wrong
> > somehow?
> >
> > It looks from the aarch64-tdep.c code like perhaps GDB assumes
> > that the Vn vector registers only exist with SVE, but they also
> > exist in SME-only CPUs.
>
> Not an ARM expert, but from what I read, SME builds on top of SVE, so I
> would guess that having SME implies having SVE.

No, it does not imply it. SVE plus SME is a very common config,
but the Apple M4 chip has SME without SVE.

-- PMM

Re: gdb support for SME-without-SVE ?

[Simon Marchi via Gdb]

On 2026-01-27 09:47, Peter Maydell wrote:
> On Tue, 27 Jan 2026 at 14:21, Simon Marchi <simark@simark.ca> wrote:
>>
>>
>>
>> On 2026-01-27 06:31, Peter Maydell via Gdb wrote:
>>> Hi: is GDB for Arm intended to support configurations where the target
>>> CPU has SME but not SVE?
>>>
>>> We're just implementing support for that in QEMU for using SME
>>> with the hvf hypervisor accelerator on macos systems, but when
>>> we tried connecting gdb to QEMU gdb crashed:
>>>
>>>   (gdb) target remote localhost:1234
>>>   Remote debugging using localhost:1234
>>>   ../../gdb/aarch64-tdep.c:3068: internal-error:
>>> aarch64_pseudo_register_type: bad register number 160
>>>   A problem internal to GDB has been detected,
>>>   further debugging may prove unreliable.
>>>   Fatal signal: Abort trap: 6
>>>
>>> https://lore.kernel.org/qemu-devel/CAAjaMXZLG2aBtStRhyvmdENj1Z+Mx05BmDgyYUoYrc_ZnHwyVQ@mail.gmail.com/
>>>
>>> Is this a known missing feature in GDB, or is it a config that's
>>> supposed to work but we've got the XML register description wrong
>>> somehow?
>>>
>>> It looks from the aarch64-tdep.c code like perhaps GDB assumes
>>> that the Vn vector registers only exist with SVE, but they also
>>> exist in SME-only CPUs.
>>
>> Not an ARM expert, but from what I read, SME builds on top of SVE, so I
>> would guess that having SME implies having SVE.
> 
> No, it does not imply it. SVE plus SME is a very common config,
> but the Apple M4 chip has SME without SVE.

Ok, I see.  Wiki says [1]:

  It is Apple's first SoC to reportedly use the ARMv9 CPU architecture.
  The M4 is based on ARMv9.2a. It supports the Scalable Matrix Extension
  (SME) but not the Scalable Vector Extension (SVE). Because of the lack
  of SVE support, the LLVM compiler officially flags the M4 as
  supporting ARMv8.7a.

And the Phoronix article it references says:

  So seeing the Apple-contributed compiler support for LLVM adding the
  M4 as an "ARMv8.7" based design was coming as a surprise. But in
  digging through the patch there is this code comment that explains the
  situation:

    "Technically apple-m4 is ARMv9.2a, but a quirk of LLVM defines v9.0
    as requiring SVE, which is optional according to the Arm ARM and not
    supported by the core. ARMv8.7a is the next closest choice."

So yeah, I guess that this use case was not expected when the
aarch64-tdep.c code was written.

Simon

[1] https://en.wikipedia.org/wiki/Apple_M4
[2] https://www.phoronix.com/news/Apple-M4-Added-To-LLVM-Clang

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Tue, 27 Jan 2026 at 11:31, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> Hi: is GDB for Arm intended to support configurations where the target
> CPU has SME but not SVE?
>
> We're just implementing support for that in QEMU for using SME
> with the hvf hypervisor accelerator on macos systems, but when
> we tried connecting gdb to QEMU gdb crashed:
>
>   (gdb) target remote localhost:1234
>   Remote debugging using localhost:1234
>   ../../gdb/aarch64-tdep.c:3068: internal-error:
> aarch64_pseudo_register_type: bad register number 160
>   A problem internal to GDB has been detected,
>   further debugging may prove unreliable.
>   Fatal signal: Abort trap: 6
>
> https://lore.kernel.org/qemu-devel/CAAjaMXZLG2aBtStRhyvmdENj1Z+Mx05BmDgyYUoYrc_ZnHwyVQ@mail.gmail.com/
>
> Is this a known missing feature in GDB, or is it a config that's
> supposed to work but we've got the XML register description wrong
> somehow?

Further investigation shows that this happened because QEMU was
accidentally reporting the zN vector registers with a width of
zero. Does gdb consider "internal error when fed bogus XML" a
bug, or just a "don't do that then" situation ? (Obviously we're
going to fix QEMU to not do that ;-))

Aside from that, I do have some questions about the GDB
remote protocol SVE and SME features where the docs at
https://sourceware.org/gdb/current/onlinedocs/gdb.html/AArch64-Features.html
are not clear to me, and I hope you can clear up my confusion.

(1) In a CPU with both SVE and SME, what does GDB expect
org.gnu.gdb.aarch64.sve "vg" to be reported as -- the SVE
vector granule, or the current vector granule taking account
of both SVE and SME? The docs can be read to support both:

https://sourceware.org/gdb/current/onlinedocs/gdb.html/AArch64.html
says both that vl/vq/vg "define the size of each Z register"
(implying it's the current vector length which might be the SVE
vector length or the streaming vector length depending on SVCR.SM)
but also "When streaming mode is enabled, the program supports
execution of SVE2 instructions and the SVE registers will have vector
length svl. When streaming mode is disabled, the SVE registers have
vector length vl", implying that vl/vq/vg are purely the SVE
vector length and that to get the actual size of the Z register
gdb will look at both vq and svq and SVCR.SM.

(2) If the CPU has SME and not SVE, presumably we should still
expose org.gnu.gdb.aarch64.sve, as it's where the z registers are.
What should we report "vl" as here? How about when the CPU is not
in streaming mode and the z regs aren't accessible?

(3) What does GDB mean when it says about the vector registers
z0..z31 in org.gnu.gdb.aarch64.sve that "Their sizes are variable"?
As far as I know once the gdbstub has handed you the XML that
fixes the size of the registers in it and they can't change
afterwards. Does this bit of the docs just mean "the stub
will give gdb a register that might be any size" ? Or is gdb
going to expect to transfer more or less data when it does a
register read/write based on the current value of vg ?
(Currently QEMU assumes that it will always get/send enough
data to completely fill the worst-case maximum vector reg
size it defined in the XML.)

My guesses as to plausible answers are:
 - for an SME-without-SVE CPU, the stub should still report
   org.gnu.gdb.aarch64.sve as well as org.gnu.gdb.aarch64.sme.

 - org.gnu.gdb.aarch64.sve 'vg' should be the current length
   of the vector registers (accounting for both SVE and SME),
   and 2 when the vector registers aren't accessible (128 bits,
   per the Arm ARM rule R_KXKNK).

 - the z regs are variable size in the protocol only in the
   sense that the stub gets to set the size when it sends the
   XML, and it sizes them to MAX(sve_max_len, sme_max_len).
   Register read and write packets then always send and
   receive that many bytes, even if the current runtime
   vector length is smaller and the tail of the vector is
   inaccessible junk.

thanks
-- PMM

Re: gdb support for SME-without-SVE ?

[Simon Marchi via Gdb]

On 2026-01-27 16:23, Peter Maydell via Gdb wrote:
> On Tue, 27 Jan 2026 at 11:31, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> Hi: is GDB for Arm intended to support configurations where the target
>> CPU has SME but not SVE?
>>
>> We're just implementing support for that in QEMU for using SME
>> with the hvf hypervisor accelerator on macos systems, but when
>> we tried connecting gdb to QEMU gdb crashed:
>>
>>   (gdb) target remote localhost:1234
>>   Remote debugging using localhost:1234
>>   ../../gdb/aarch64-tdep.c:3068: internal-error:
>> aarch64_pseudo_register_type: bad register number 160
>>   A problem internal to GDB has been detected,
>>   further debugging may prove unreliable.
>>   Fatal signal: Abort trap: 6
>>
>> https://lore.kernel.org/qemu-devel/CAAjaMXZLG2aBtStRhyvmdENj1Z+Mx05BmDgyYUoYrc_ZnHwyVQ@mail.gmail.com/
>>
>> Is this a known missing feature in GDB, or is it a config that's
>> supposed to work but we've got the XML register description wrong
>> somehow?
> 
> Further investigation shows that this happened because QEMU was
> accidentally reporting the zN vector registers with a width of
> zero. Does gdb consider "internal error when fed bogus XML" a
> bug, or just a "don't do that then" situation ? (Obviously we're
> going to fix QEMU to not do that ;-))

Yes, it's a bug: bad input should not cause an internal error, there
should be proper error reporting.  It's probably a very low prio bug,
but if you want to contribute a fix we'd be happy to have it :).

I can't help with your other AArch64-specific questions, sorry.

Simon

Re: gdb support for SME-without-SVE ?

[Luis via Gdb]

On Tue, Jan 27, 2026, 21:24 Peter Maydell <peter.maydell@linaro.org> wrote:

> On Tue, 27 Jan 2026 at 11:31, Peter Maydell <peter.maydell@linaro.org>
> wrote:
> >
> > Hi: is GDB for Arm intended to support configurations where the target
> > CPU has SME but not SVE?
> >
> > We're just implementing support for that in QEMU for using SME
> > with the hvf hypervisor accelerator on macos systems, but when
> > we tried connecting gdb to QEMU gdb crashed:
> >
> >   (gdb) target remote localhost:1234
> >   Remote debugging using localhost:1234
> >   ../../gdb/aarch64-tdep.c:3068: internal-error:
> > aarch64_pseudo_register_type: bad register number 160
> >   A problem internal to GDB has been detected,
> >   further debugging may prove unreliable.
> >   Fatal signal: Abort trap: 6
> >
> >
> https://lore.kernel.org/qemu-devel/CAAjaMXZLG2aBtStRhyvmdENj1Z+Mx05BmDgyYUoYrc_ZnHwyVQ@mail.gmail.com/
> >
> > Is this a known missing feature in GDB, or is it a config that's
> > supposed to work but we've got the XML register description wrong
> > somehow?
>
> Further investigation shows that this happened because QEMU was
> accidentally reporting the zN vector registers with a width of
> zero. Does gdb consider "internal error when fed bogus XML" a
> bug, or just a "don't do that then" situation ? (Obviously we're
> going to fix QEMU to not do that ;-))
>
> Aside from that, I do have some questions about the GDB
> remote protocol SVE and SME features where the docs at
>
> https://sourceware.org/gdb/current/onlinedocs/gdb.html/AArch64-Features.html
> are not clear to me, and I hope you can clear up my confusion.
>
> (1) In a CPU with both SVE and SME, what does GDB expect
> org.gnu.gdb.aarch64.sve "vg" to be reported as -- the SVE
> vector granule, or the current vector granule taking account
> of both SVE and SME? The docs can be read to support both:
>

vg is for SVE and svg is for SME and SSVE.

When in streaming mode the Z registers will use svg instead of vg.



> https://sourceware.org/gdb/current/onlinedocs/gdb.html/AArch64.html
> says both that vl/vq/vg "define the size of each Z register"
> (implying it's the current vector length which might be the SVE
> vector length or the streaming vector length depending on SVCR.SM)
> but also "When streaming mode is enabled, the program supports
> execution of SVE2 instructions and the SVE registers will have vector
> length svl. When streaming mode is disabled, the SVE registers have
> vector length vl", implying that vl/vq/vg are purely the SVE
> vector length and that to get the actual size of the Z register
> gdb will look at both vq and svq and SVCR.SM.
>
> (2) If the CPU has SME and not SVE, presumably we should still
> expose org.gnu.gdb.aarch64.sve, as it's where the z registers are.
> What should we report "vl" as here? How about when the CPU is not
> in streaming mode and the z regs aren't accessible?
>

Are there still Z registers without SVE?

I don't think this is properly supported in any case. On top of that SVE
and SME are not properly supported via the remote protocol. In theory it
works if you don't change vg/svg mid-execution. So no SSVE enabling etc.
But in practice it does not work well. When the vg/svg size changes you end
up with overruns or garbage.

The initial implementation of SVE assumed remote debugging wasn't
important. We're stuck with that until remote protocol enhancements are
contributed.

Those enhancements have been proposed multiple times but there were always
downsides and it tends to die and fall into limbo. It mostly only affects
SVE and SME. Maybe AMX.



> (3) What does GDB mean when it says about the vector registers
> z0..z31 in org.gnu.gdb.aarch64.sve that "Their sizes are variable"?
> As far as I know once the gdbstub has handed you the XML that
> fixes the size of the registers in it and they can't change
> afterwards. Does this bit of the docs just mean "the stub
> will give gdb a register that might be any size" ? Or is gdb
> going to expect to transfer more or less data when it does a
> register read/write based on the current value of vg ?
> (Currently QEMU assumes that it will always get/send enough
> data to completely fill the worst-case maximum vector reg
> size it defined in the XML.)
>

Technically that is not how it should work. For SVE and SME we would expect
the register data to match the current size of vg/svg. But like I said
above, this does not even work for remote protocol SVE and SME until that
restriction of a single XML per debugging session is lifted.

Native gdb uses per-thread XML descriptions. That is why it manages to
toggle the sizes of SVE and SME registers. Remote stubs use a single XML.

Hopefully that provided some clarity.


> My guesses as to plausible answers are:
>  - for an SME-without-SVE CPU, the stub should still report
>    org.gnu.gdb.aarch64.sve as well as org.gnu.gdb.aarch64.sme.
>
>  - org.gnu.gdb.aarch64.sve 'vg' should be the current length
>    of the vector registers (accounting for both SVE and SME),
>    and 2 when the vector registers aren't accessible (128 bits,
>    per the Arm ARM rule R_KXKNK).
>
>  - the z regs are variable size in the protocol only in the
>    sense that the stub gets to set the size when it sends the
>    XML, and it sizes them to MAX(sve_max_len, sme_max_len).
>    Register read and write packets then always send and
>    receive that many bytes, even if the current runtime
>    vector length is smaller and the tail of the vector is
>    inaccessible junk.
>
> thanks
> -- PMM
>

Re: gdb support for SME-without-SVE ?

[Thiago Jung Bauermann via Gdb]

Hello,

I'm currently implementing SME-only (i.e. without SVE) support in GDB
for Linux userspace debugging. It's mostly done, I just need to test a
few things, polish the code and prepare the patches. I'm hoping to send
the patches next week.

Due to the limitations in the remote protocol that Luis mentioned below,
I can't run the tests against a remote target so I'm only focusing on
local debugging, unfortunately.

Luis <luis.machado.foss@gmail.com> writes:

> On Tue, Jan 27, 2026, 21:24 Peter Maydell <peter.maydell@linaro.org> wrote:
>
> > (2) If the CPU has SME and not SVE, presumably we should still
> > expose org.gnu.gdb.aarch64.sve, as it's where the z registers are.
> > What should we report "vl" as here? How about when the CPU is not
> > in streaming mode and the z regs aren't accessible?
>
> Are there still Z registers without SVE?

Yes, but they are only accessible while in streaming mode.

For simplicity, if the inferior isn't in streaming mode I'm making the
SVE registers available in non-streaming mode (i.e., behave as if SVE is
supported) with vg = 2 as Peter mentions below. In this case, the Z
registers are equivalent to the regular vector registers.

> I don't think this is properly supported in any case. On top of that
> SVE and SME are not properly supported via the remote protocol.  In
> theory it works if you don't change vg/svg mid-execution. So no SSVE
> enabling etc. But in practice it does not work well. When the vg/svg
> size changes you end up with overruns or garbage.
>
> The initial implementation of SVE assumed remote debugging wasn't
> important. We're stuck with that until remote protocol enhancements
> are contributed.
>
> Those enhancements have been proposed multiple times but there were
> always downsides and it tends to die and fall into limbo.  It mostly
> only affects SVE and SME. Maybe AMX.

I'm planning to resume this work again in the next few months. Christina
and Klaus from Intel came up with a nice proposal.

-- 
Thiago

Re: gdb support for SME-without-SVE ?

[Luis via Gdb]

On Wed, Jan 28, 2026, 04:24 Thiago Jung Bauermann <
thiago.bauermann@linaro.org> wrote:

> Hello,
>
> I'm currently implementing SME-only (i.e. without SVE) support in GDB
> for Linux userspace debugging. It's mostly done, I just need to test a
> few things, polish the code and prepare the patches. I'm hoping to send
> the patches next week.
>

Excellent. Thanks for the heads up.



> Due to the limitations in the remote protocol that Luis mentioned below,
> I can't run the tests against a remote target so I'm only focusing on
> local debugging, unfortunately.
>
> Luis <luis.machado.foss@gmail.com> writes:
>
> > On Tue, Jan 27, 2026, 21:24 Peter Maydell <peter.maydell@linaro.org>
> wrote:
> >
> > > (2) If the CPU has SME and not SVE, presumably we should still
> > > expose org.gnu.gdb.aarch64.sve, as it's where the z registers are.
> > > What should we report "vl" as here? How about when the CPU is not
> > > in streaming mode and the z regs aren't accessible?
> >
> > Are there still Z registers without SVE?
>
> Yes, but they are only accessible while in streaming mode.
>
> For simplicity, if the inferior isn't in streaming mode I'm making the
> SVE registers available in non-streaming mode (i.e., behave as if SVE is
> supported) with vg = 2 as Peter mentions below. In this case, the Z
> registers are equivalent to the regular vector registers.
>
> > I don't think this is properly supported in any case. On top of that
> > SVE and SME are not properly supported via the remote protocol.  In
> > theory it works if you don't change vg/svg mid-execution. So no SSVE
> > enabling etc. But in practice it does not work well. When the vg/svg
> > size changes you end up with overruns or garbage.
> >
> > The initial implementation of SVE assumed remote debugging wasn't
> > important. We're stuck with that until remote protocol enhancements
> > are contributed.
> >
> > Those enhancements have been proposed multiple times but there were
> > always downsides and it tends to die and fall into limbo.  It mostly
> > only affects SVE and SME. Maybe AMX.
>
> I'm planning to resume this work again in the next few months. Christina
> and Klaus from Intel came up with a nice proposal.
>

Great. Hopefully we can get this restriction lifted and enable dynamic
sizes for remote stubs.



> --
> Thiago
>

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Wed, 28 Jan 2026 at 04:24, Thiago Jung Bauermann
<thiago.bauermann@linaro.org> wrote:
> I'm currently implementing SME-only (i.e. without SVE) support in GDB
> for Linux userspace debugging. It's mostly done, I just need to test a
> few things, polish the code and prepare the patches. I'm hoping to send
> the patches next week.

Let me know if a QEMU setup emulating "SME only" would be helpful
for you with that.

> Due to the limitations in the remote protocol that Luis mentioned below,
> I can't run the tests against a remote target so I'm only focusing on
> local debugging, unfortunately.

What does gdb need to do differently for "SME only" vs "SME + SVE" ?

What I'm wondering is, if for the remote protocol we define/redefine:
 - org.gnu.gdb.aarch64.sve is how the Z registers are exposed; its
   'vg' tells you the size of the Z regs (either "max size" as
   currently, or eventually "current size", 128 bits if Z regs
   not currently exposed)
 - org.gnu.gdb.aarch64.sme is how the ZA array is exposed; its
   'svg' tells you the size of the ZA array

then does this break something subtly ? I think with current gdb
it would let you at least access all the registers without it
falling over. gdb wouldn't be able to tell the difference between
"SME only" and "SME + SVE" if we define things this way; but we
could add a new thing somewhere if it needs that information.

(Handling changes in vector length would obviously be the ideal,
but we don't have that at the moment for anything.)

thanks
-- PMM

Re: gdb support for SME-without-SVE ?

[Thiago Jung Bauermann via Gdb]

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

> On Wed, 28 Jan 2026 at 04:24, Thiago Jung Bauermann
> <thiago.bauermann@linaro.org> wrote:
>> I'm currently implementing SME-only (i.e. without SVE) support in GDB
>> for Linux userspace debugging. It's mostly done, I just need to test a
>> few things, polish the code and prepare the patches. I'm hoping to send
>> the patches next week.
>
> Let me know if a QEMU setup emulating "SME only" would be helpful
> for you with that.

It would indeed! If there's a branch I can build, it would make my
testing quicker, and the regression testing more complete.

>> Due to the limitations in the remote protocol that Luis mentioned below,
>> I can't run the tests against a remote target so I'm only focusing on
>> local debugging, unfortunately.
>
> What does gdb need to do differently for "SME only" vs "SME + SVE" ?

There are two changes:

1. GDB assumed that whenever SME was available, then SVE was too and it
   would try to also fetch the SVE register set when it decided to fetch
   the SME register set.

2. Since GDB pretends the SVE register set (i.e., the
   org.gnu.gdb.aarch64.sve XML feature) is always there, when the SVE
   register set is needed and the inferior isn't in streaming mode then
   GDB needs to fetch/set the FPSIMD register set instead, and pretend
   that VL is 128 bits as you mentioned.

> What I'm wondering is, if for the remote protocol we define/redefine:
>  - org.gnu.gdb.aarch64.sve is how the Z registers are exposed; its
>    'vg' tells you the size of the Z regs (either "max size" as
>    currently, or eventually "current size", 128 bits if Z regs
>    not currently exposed)
>  - org.gnu.gdb.aarch64.sme is how the ZA array is exposed; its
>    'svg' tells you the size of the ZA array
>
> then does this break something subtly ? I think with current gdb
> it would let you at least access all the registers without it
> falling over. gdb wouldn't be able to tell the difference between
> "SME only" and "SME + SVE" if we define things this way; but we
> could add a new thing somewhere if it needs that information.

I think that should work fine. If the stub can always provide and accept
values for the Z registers, and if the Z registers have the size that
the VG register says they should have then GDB will be happy.

The changes I mentioned above stem from the fact that ptrace() rejects
calls referencing the NT_ARM_SVE regset in SME-only, and only allow
NT_ARM_SSVE if the inferior is in streaming mode. The remote protocol
doesn't need to expose these restrictions.

-- 
Thiago

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Thu, 29 Jan 2026 at 04:12, Thiago Jung Bauermann
<thiago.bauermann@linaro.org> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Wed, 28 Jan 2026 at 04:24, Thiago Jung Bauermann
> > <thiago.bauermann@linaro.org> wrote:
> >> I'm currently implementing SME-only (i.e. without SVE) support in GDB
> >> for Linux userspace debugging. It's mostly done, I just need to test a
> >> few things, polish the code and prepare the patches. I'm hoping to send
> >> the patches next week.
> >
> > Let me know if a QEMU setup emulating "SME only" would be helpful
> > for you with that.
>
> It would indeed! If there's a branch I can build, it would make my
> testing quicker, and the regression testing more complete.

I'll get one sorted out later today (the patches I have right now
have a few issues I need to fix).

> >> Due to the limitations in the remote protocol that Luis mentioned below,
> >> I can't run the tests against a remote target so I'm only focusing on
> >> local debugging, unfortunately.
> >
> > What does gdb need to do differently for "SME only" vs "SME + SVE" ?
>
> There are two changes:
>
> 1. GDB assumed that whenever SME was available, then SVE was too and it
>    would try to also fetch the SVE register set when it decided to fetch
>    the SME register set.
>
> 2. Since GDB pretends the SVE register set (i.e., the
>    org.gnu.gdb.aarch64.sve XML feature) is always there, when the SVE
>    register set is needed and the inferior isn't in streaming mode then
>    GDB needs to fetch/set the FPSIMD register set instead, and pretend
>    that VL is 128 bits as you mentioned.
>
> > What I'm wondering is, if for the remote protocol we define/redefine:
> >  - org.gnu.gdb.aarch64.sve is how the Z registers are exposed; its
> >    'vg' tells you the size of the Z regs (either "max size" as
> >    currently, or eventually "current size", 128 bits if Z regs
> >    not currently exposed)
> >  - org.gnu.gdb.aarch64.sme is how the ZA array is exposed; its
> >    'svg' tells you the size of the ZA array
> >
> > then does this break something subtly ? I think with current gdb
> > it would let you at least access all the registers without it
> > falling over. gdb wouldn't be able to tell the difference between
> > "SME only" and "SME + SVE" if we define things this way; but we
> > could add a new thing somewhere if it needs that information.
>
> I think that should work fine. If the stub can always provide and accept
> values for the Z registers, and if the Z registers have the size that
> the VG register says they should have then GDB will be happy.
>
> The changes I mentioned above stem from the fact that ptrace() rejects
> calls referencing the NT_ARM_SVE regset in SME-only, and only allow
> NT_ARM_SSVE if the inferior is in streaming mode. The remote protocol
> doesn't need to expose these restrictions.

Great. I'll move forward on that assumption for my prototype
patches. I might have a go at a proposed documentation patch
that writes up the above as the defined requirements, but that
will be the last thing on my todo list so if anybody else would
like to do that please feel free.

thanks
-- PMM

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Thu, 29 Jan 2026 at 09:10, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Thu, 29 Jan 2026 at 04:12, Thiago Jung Bauermann
> <thiago.bauermann@linaro.org> wrote:
> >
> > Peter Maydell <peter.maydell@linaro.org> writes:
> >
> > > On Wed, 28 Jan 2026 at 04:24, Thiago Jung Bauermann
> > > <thiago.bauermann@linaro.org> wrote:
> > >> I'm currently implementing SME-only (i.e. without SVE) support in GDB
> > >> for Linux userspace debugging. It's mostly done, I just need to test a
> > >> few things, polish the code and prepare the patches. I'm hoping to send
> > >> the patches next week.
> > >
> > > Let me know if a QEMU setup emulating "SME only" would be helpful
> > > for you with that.
> >
> > It would indeed! If there's a branch I can build, it would make my
> > testing quicker, and the regression testing more complete.
>
> I'll get one sorted out later today (the patches I have right now
> have a few issues I need to fix).

This branch:

https://gitlab.com/pm215/qemu/-/commits/sme-no-sve

should let you create an SME-only CPU with "-cpu max,sve=off".
I have not given it much more than a very cursory testing, so
let me know if you run into any problems with it.

thanks
-- PMM

Re: gdb support for SME-without-SVE ?

[Thiago Jung Bauermann via Gdb]

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

> On Thu, 29 Jan 2026 at 09:10, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On Thu, 29 Jan 2026 at 04:12, Thiago Jung Bauermann
>> <thiago.bauermann@linaro.org> wrote:
>> >
>> > Peter Maydell <peter.maydell@linaro.org> writes:
>> >
>> > > On Wed, 28 Jan 2026 at 04:24, Thiago Jung Bauermann
>> > > <thiago.bauermann@linaro.org> wrote:
>> > >> I'm currently implementing SME-only (i.e. without SVE) support in GDB
>> > >> for Linux userspace debugging. It's mostly done, I just need to test a
>> > >> few things, polish the code and prepare the patches. I'm hoping to send
>> > >> the patches next week.
>> > >
>> > > Let me know if a QEMU setup emulating "SME only" would be helpful
>> > > for you with that.
>> >
>> > It would indeed! If there's a branch I can build, it would make my
>> > testing quicker, and the regression testing more complete.
>>
>> I'll get one sorted out later today (the patches I have right now
>> have a few issues I need to fix).
>
> This branch:
>
> https://gitlab.com/pm215/qemu/-/commits/sme-no-sve

Thank you very much!

> should let you create an SME-only CPU with "-cpu max,sve=off".
> I have not given it much more than a very cursory testing, so
> let me know if you run into any problems with it.

Unfortunately I hit a kernel oops reliably when trying to run a GDB testcase:

[  156.387143] Internal error: Oops - Undefined instruction: 0000000002000000 [#1]  SMP
[  156.389966] Modules linked in: sm3_ce tpm_tis tpm_tis_core sha256 cfg80211 rfkill fuse drm backlight dm_mod ipv6 btrfs blake2b libblake2b xor xor_neon raid6_pq zstd_compress
[  156.391005] CPU: 0 UID: 1000 PID: 677 Comm: aarch64-sme-san Not tainted 6.19.0-rc5 #4 PREEMPT
[  156.391244] Hardware name: QEMU QEMU Virtual Machine, BIOS edk2-stable202408-prebuilt.qemu.org 08/13/2024
[  156.391475] pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[  156.391657] pc : sve_get_vl+0x4/0xc
[  156.392149] lr : fpsimd_save_user_state+0x100/0x1b8
[  156.392270] sp : ffff800080cbbb80
[  156.392329] x29: ffff800080cbbb80 x28: 0000000000000001 x27: fff00000c44b05e0
[  156.392501] x26: ffff800080cbbdf0 x25: 0000000000000000 x24: 0000000000000000
[  156.392627] x23: 0000000000000000 x22: fff05a09d4047000 x21: 0000000000000020
[  156.392745] x20: fff00000ff5380f0 x19: ffffa5f72b4f10f0 x18: 0000000000000000
[  156.392870] x17: 0000000000000000 x16: 0000000000000000 x15: 02ed5d640eed9128
[  156.392994] x14: 0000b00e8e55cf08 x13: 000000000000033b x12: 000000000000033b
[  156.393109] x11: 0000000000000000 x10: 0000000000000002 x9 : 0000000000000800
[  156.393246] x8 : fff00000c36aac80 x7 : fff00000c36aac00 x6 : 00000007fb30b524
[  156.393372] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffff800080cbbc60
[  156.393491] x2 : 0000000000000000 x1 : fff00000c44b0000 x0 : 0000000000000001
[  156.393681] Call trace:
[  156.393853]  sve_get_vl+0x4/0xc (P)
[  156.394027]  fpsimd_thread_switch+0x44/0x188
[  156.394125]  __switch_to+0x20/0x1a8
[  156.394203]  __schedule+0x368/0xcdc
[  156.394270]  schedule+0x34/0x110
[  156.394328]  ptrace_stop.part.0+0x12c/0x24c
[  156.394409]  get_signal+0x384/0x82c
[  156.394471]  arch_do_signal_or_restart+0x118/0x3c4
[  156.394555]  exit_to_user_mode_loop+0x104/0x16c
[  156.394640]  el0_undef+0x88/0x8c
[  156.394704]  el0t_64_sync_handler+0x70/0xe4
[  156.394779]  el0t_64_sync+0x198/0x19c
[  156.394973] Code: b9400424 d51b4404 d65f03c0 d503245f (04bf5020)
[  156.395301] ---[ end trace 0000000000000000 ]---

The same kernel and userspace binaries work fine in Arm FVP.

In case you want to try it, this is my GDB branch:

https://gitlab.com/bauermann/binutils-gdb/-/commits/sme-only

And you can run the testcase with:

$ cd /path/to/gdb/build/dir; make check-gdb TESTS=gdb.arch/aarch64-sme-sanity.exp

I can try to create a minimal reproducer if it will help.

My QEMU command line is:

$QEMU_PREFIX/bin/qemu-system-aarch64 \
    -M virt \
    -cpu max,sve=off \
    -m 4g \
    -drive if=none,file=$HOME/VMs/ubuntu-aarch64.img,id=hd1,format=raw,cache=writeback,discard=on \
    -device virtio-blk-device,drive=hd1 \
    -netdev user,id=mynet0,hostfwd=tcp::8022-:22 -device virtio-net-pci,netdev=mynet0 \
    -bios $QEMU_PREFIX/share/qemu/edk2-aarch64-code.fd \
    -nographic

-- 
Thiago

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Fri, 30 Jan 2026 at 04:28, Thiago Jung Bauermann
<thiago.bauermann@linaro.org> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Thu, 29 Jan 2026 at 09:10, Peter Maydell <peter.maydell@linaro.org> wrote:
> >>
> >> On Thu, 29 Jan 2026 at 04:12, Thiago Jung Bauermann
> >> <thiago.bauermann@linaro.org> wrote:
> >> >
> >> > Peter Maydell <peter.maydell@linaro.org> writes:
> >> >
> >> > > On Wed, 28 Jan 2026 at 04:24, Thiago Jung Bauermann
> >> > > <thiago.bauermann@linaro.org> wrote:
> >> > >> I'm currently implementing SME-only (i.e. without SVE) support in GDB
> >> > >> for Linux userspace debugging. It's mostly done, I just need to test a
> >> > >> few things, polish the code and prepare the patches. I'm hoping to send
> >> > >> the patches next week.
> >> > >
> >> > > Let me know if a QEMU setup emulating "SME only" would be helpful
> >> > > for you with that.
> >> >
> >> > It would indeed! If there's a branch I can build, it would make my
> >> > testing quicker, and the regression testing more complete.
> >>
> >> I'll get one sorted out later today (the patches I have right now
> >> have a few issues I need to fix).
> >
> > This branch:
> >
> > https://gitlab.com/pm215/qemu/-/commits/sme-no-sve
>
> Thank you very much!
>
> > should let you create an SME-only CPU with "-cpu max,sve=off".
> > I have not given it much more than a very cursory testing, so
> > let me know if you run into any problems with it.
>
> Unfortunately I hit a kernel oops reliably when trying to run a GDB testcase:
>
> [  156.387143] Internal error: Oops - Undefined instruction: 0000000002000000 [#1]  SMP

> The same kernel and userspace binaries work fine in Arm FVP.

Thanks for testing -- this looks like it's going to be a QEMU
bug where we're accidentally making something UNDEF when it
should work when SME is present. I'll have a look at it.

-- PMM

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Fri, 30 Jan 2026 at 04:28, Thiago Jung Bauermann
<thiago.bauermann@linaro.org> wrote:
> Unfortunately I hit a kernel oops reliably when trying to run a GDB testcase:
>
> [  156.387143] Internal error: Oops - Undefined instruction: 0000000002000000 [#1]  SMP
> [  156.389966] Modules linked in: sm3_ce tpm_tis tpm_tis_core sha256 cfg80211 rfkill fuse drm backlight dm_mod ipv6 btrfs blake2b libblake2b xor xor_neon raid6_pq zstd_compress
> [  156.391005] CPU: 0 UID: 1000 PID: 677 Comm: aarch64-sme-san Not tainted 6.19.0-rc5 #4 PREEMPT
> [  156.391244] Hardware name: QEMU QEMU Virtual Machine, BIOS edk2-stable202408-prebuilt.qemu.org 08/13/2024
> [  156.391475] pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
> [  156.391657] pc : sve_get_vl+0x4/0xc
> [  156.392149] lr : fpsimd_save_user_state+0x100/0x1b8

So I know what this bug is, but I'm having difficulty with
reproducing it. I got it to reproduce just once, after I did a
full build of gdb and then ran the test case with your command:

> And you can run the testcase with:
>
> $ cd /path/to/gdb/build/dir; make check-gdb TESTS=gdb.arch/aarch64-sme-sanity.exp

But now after restarting the VM and running this command again,
it does nothing:

root@debian:~/gdb-build# make check-gdb TESTS=gdb.arch/aarch64-sme-sanity.exp
make[1]: Entering directory '/root/gdb-build/gdb'
make[2]: Entering directory '/root/gdb-build/gdb/testsuite'
make check-single
make[3]: Entering directory '/root/gdb-build/gdb/testsuite'
rm -f *core* gdb.sum gdb.log
rootme=`pwd`; export rootme;
srcdir=../../../binutils-gdb/gdb/testsuite ; export srcdir ;
EXPECT=`if [ "${READ1}" != "" ] ; then echo ${rootme}/expect-read1;
elif [ "${READMORE}" != "" ] ; then echo ${rootme}/expect-readmore;
elif [ -f ${rootme}/../../expect/expect ] ; then echo
${rootme}/../../expect/expect ; else echo expect ; fi` ; export EXPECT
; EXEEXT= ; export EXEEXT ;
LD_LIBRARY_PATH=$rootme/../../expect:$rootme/../../libstdc++:$rootme/../../tk/unix:$rootme/../../tcl/unix:$rootme/../../bfd:$rootme/../../opcodes:$LD_LIBRARY_PATH;
export LD_LIBRARY_PATH; if [ -f ${rootme}/../../expect/expect ] ; then
TCL_LIBRARY=${srcdir}/../../tcl/library ; export TCL_LIBRARY ; fi ;
runtest --status  gdb.arch/aarch64-sme-sanity.exp ; \
result=$?; \
if test -e gdb.sum; then \
  /bin/bash ../../../binutils-gdb/gdb/testsuite/lib/dg-add-core-file-count.sh; \
  sed -n '/=== gdb Summary ===/,$ p' gdb.sum; \
fi; \
exit $result
WARNING: No tool specified
Test run by root on Fri Jan 30 12:25:14 2026
Native configuration is aarch64-unknown-linux-gnu

                ===  tests ===

Schedule of variations:
    unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
WARNING: Couldn't find tool config file for unix, using default.

                ===  Summary ===

make[3]: Leaving directory '/root/gdb-build/gdb/testsuite'
make[2]: Leaving directory '/root/gdb-build/gdb/testsuite'
make[1]: Leaving directory '/root/gdb-build/gdb'
root@debian:~/gdb-build#

As far as I can see the test harness is running no tests any more
(and so the kernel oops doesn't show up).

Is there some way I can get it to tell me why it isn't running anything?

thanks
-- PMM

Re: gdb support for SME-without-SVE ?

[Thiago Jung Bauermann via Gdb]

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

> But now after restarting the VM and running this command again,
> it does nothing:
>
> root@debian:~/gdb-build# make check-gdb TESTS=gdb.arch/aarch64-sme-sanity.exp
> make[1]: Entering directory '/root/gdb-build/gdb'
> make[2]: Entering directory '/root/gdb-build/gdb/testsuite'
> make check-single
> make[3]: Entering directory '/root/gdb-build/gdb/testsuite'
> rm -f *core* gdb.sum gdb.log
> rootme=`pwd`; export rootme;
> srcdir=../../../binutils-gdb/gdb/testsuite ; export srcdir ;
> EXPECT=`if [ "${READ1}" != "" ] ; then echo ${rootme}/expect-read1;
> elif [ "${READMORE}" != "" ] ; then echo ${rootme}/expect-readmore;
> elif [ -f ${rootme}/../../expect/expect ] ; then echo
> ${rootme}/../../expect/expect ; else echo expect ; fi` ; export EXPECT
> ; EXEEXT= ; export EXEEXT ;
> LD_LIBRARY_PATH=$rootme/../../expect:$rootme/../../libstdc++:$rootme/../../tk/unix:$rootme/../../tcl/unix:$rootme/../../bfd:$rootme/../../opcodes:$LD_LIBRARY_PATH;
> export LD_LIBRARY_PATH; if [ -f ${rootme}/../../expect/expect ] ; then
> TCL_LIBRARY=${srcdir}/../../tcl/library ; export TCL_LIBRARY ; fi ;
> runtest --status  gdb.arch/aarch64-sme-sanity.exp ; \
> result=$?; \
> if test -e gdb.sum; then \
>   /bin/bash ../../../binutils-gdb/gdb/testsuite/lib/dg-add-core-file-count.sh; \
>   sed -n '/=== gdb Summary ===/,$ p' gdb.sum; \
> fi; \
> exit $result
> WARNING: No tool specified
> Test run by root on Fri Jan 30 12:25:14 2026
> Native configuration is aarch64-unknown-linux-gnu
>
>                 ===  tests ===
>
> Schedule of variations:
>     unix
>
> Running target unix
> Using /usr/share/dejagnu/baseboards/unix.exp as board description file
> for target.
> Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
> WARNING: Couldn't find tool config file for unix, using default.

Hm, weird. I don't know about this problem. Sounds like some generated
Dejagnu config file is missing. Maybe try running just "make" before
"make check-gdb" to see if the file is generated again?

>                 ===  Summary ===
>
> make[3]: Leaving directory '/root/gdb-build/gdb/testsuite'
> make[2]: Leaving directory '/root/gdb-build/gdb/testsuite'
> make[1]: Leaving directory '/root/gdb-build/gdb'
> root@debian:~/gdb-build#
>
> As far as I can see the test harness is running no tests any more
> (and so the kernel oops doesn't show up).
>
> Is there some way I can get it to tell me why it isn't running anything?

The gdb.log file sometimes has more information than what appears on the
console.

-- 
Thiago

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Fri, 30 Jan 2026 at 16:16, Thiago Jung Bauermann
<thiago.bauermann@linaro.org> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > But now after restarting the VM and running this command again,
> > it does nothing:
> >
> > root@debian:~/gdb-build# make check-gdb TESTS=gdb.arch/aarch64-sme-sanity.exp
> > make[1]: Entering directory '/root/gdb-build/gdb'
> > make[2]: Entering directory '/root/gdb-build/gdb/testsuite'
> > make check-single
> > make[3]: Entering directory '/root/gdb-build/gdb/testsuite'
> > rm -f *core* gdb.sum gdb.log
> > rootme=`pwd`; export rootme;
> > srcdir=../../../binutils-gdb/gdb/testsuite ; export srcdir ;
> > EXPECT=`if [ "${READ1}" != "" ] ; then echo ${rootme}/expect-read1;
> > elif [ "${READMORE}" != "" ] ; then echo ${rootme}/expect-readmore;
> > elif [ -f ${rootme}/../../expect/expect ] ; then echo
> > ${rootme}/../../expect/expect ; else echo expect ; fi` ; export EXPECT
> > ; EXEEXT= ; export EXEEXT ;
> > LD_LIBRARY_PATH=$rootme/../../expect:$rootme/../../libstdc++:$rootme/../../tk/unix:$rootme/../../tcl/unix:$rootme/../../bfd:$rootme/../../opcodes:$LD_LIBRARY_PATH;
> > export LD_LIBRARY_PATH; if [ -f ${rootme}/../../expect/expect ] ; then
> > TCL_LIBRARY=${srcdir}/../../tcl/library ; export TCL_LIBRARY ; fi ;
> > runtest --status  gdb.arch/aarch64-sme-sanity.exp ; \
> > result=$?; \
> > if test -e gdb.sum; then \
> >   /bin/bash ../../../binutils-gdb/gdb/testsuite/lib/dg-add-core-file-count.sh; \
> >   sed -n '/=== gdb Summary ===/,$ p' gdb.sum; \
> > fi; \
> > exit $result
> > WARNING: No tool specified
> > Test run by root on Fri Jan 30 12:25:14 2026
> > Native configuration is aarch64-unknown-linux-gnu
> >
> >                 ===  tests ===
> >
> > Schedule of variations:
> >     unix
> >
> > Running target unix
> > Using /usr/share/dejagnu/baseboards/unix.exp as board description file
> > for target.
> > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
> > WARNING: Couldn't find tool config file for unix, using default.
>
> Hm, weird. I don't know about this problem. Sounds like some generated
> Dejagnu config file is missing. Maybe try running just "make" before
> "make check-gdb" to see if the file is generated again?

I did try that, but it didn't help. ("Some file that dejagnu created
is corrupt/truncated" seems quite possible, because I had to kill
the VM after the guest kernel hit the Oops.)

> > Is there some way I can get it to tell me why it isn't running anything?
>
> The gdb.log file sometimes has more information than what appears on the
> console.

Where would I find it? (The make output suggests it would be
in gdb/testsuite/ as that is what the rm command deletes, but
there is no gdb.log file in that directory.)

Is there something I can rm in my build directory that will delete
all the testsuite stuff and force it to recreate it ? (I would
prefer not to have to blow away the whole build directory and
spend hours waiting for gdb to be rebuilt...)

thanks
-- PMM

Re: gdb support for SME-without-SVE ?

[Thiago Jung Bauermann via Gdb]

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

> On Fri, 30 Jan 2026 at 16:16, Thiago Jung Bauermann
> <thiago.bauermann@linaro.org> wrote:
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>> > But now after restarting the VM and running this command again,
>> > it does nothing:
>> >
>> > root@debian:~/gdb-build# make check-gdb TESTS=gdb.arch/aarch64-sme-sanity.exp
>> > make[1]: Entering directory '/root/gdb-build/gdb'
>> > make[2]: Entering directory '/root/gdb-build/gdb/testsuite'
>> > make check-single
>> > make[3]: Entering directory '/root/gdb-build/gdb/testsuite'
>> > rm -f *core* gdb.sum gdb.log
>> > rootme=`pwd`; export rootme;
>> > srcdir=../../../binutils-gdb/gdb/testsuite ; export srcdir ;
>> > EXPECT=`if [ "${READ1}" != "" ] ; then echo ${rootme}/expect-read1;
>> > elif [ "${READMORE}" != "" ] ; then echo ${rootme}/expect-readmore;
>> > elif [ -f ${rootme}/../../expect/expect ] ; then echo
>> > ${rootme}/../../expect/expect ; else echo expect ; fi` ; export EXPECT
>> > ; EXEEXT= ; export EXEEXT ;
>> > LD_LIBRARY_PATH=$rootme/../../expect:$rootme/../../libstdc++:$rootme/../../tk/unix:$rootme/../../tcl/unix:$rootme/../../bfd:$rootme/../../opcodes:$LD_LIBRARY_PATH;
>> > export LD_LIBRARY_PATH; if [ -f ${rootme}/../../expect/expect ] ; then
>> > TCL_LIBRARY=${srcdir}/../../tcl/library ; export TCL_LIBRARY ; fi ;
>> > runtest --status  gdb.arch/aarch64-sme-sanity.exp ; \
>> > result=$?; \
>> > if test -e gdb.sum; then \
>> >   /bin/bash ../../../binutils-gdb/gdb/testsuite/lib/dg-add-core-file-count.sh; \
>> >   sed -n '/=== gdb Summary ===/,$ p' gdb.sum; \
>> > fi; \
>> > exit $result
>> > WARNING: No tool specified
>> > Test run by root on Fri Jan 30 12:25:14 2026
>> > Native configuration is aarch64-unknown-linux-gnu
>> >
>> >                 ===  tests ===
>> >
>> > Schedule of variations:
>> >     unix
>> >
>> > Running target unix
>> > Using /usr/share/dejagnu/baseboards/unix.exp as board description file
>> > for target.
>> > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
>> > WARNING: Couldn't find tool config file for unix, using default.
>>
>> Hm, weird. I don't know about this problem. Sounds like some generated
>> Dejagnu config file is missing. Maybe try running just "make" before
>> "make check-gdb" to see if the file is generated again?
>
> I did try that, but it didn't help. ("Some file that dejagnu created
> is corrupt/truncated" seems quite possible, because I had to kill
> the VM after the guest kernel hit the Oops.)

Ah, that's probably it then.

>> > Is there some way I can get it to tell me why it isn't running anything?
>>
>> The gdb.log file sometimes has more information than what appears on the
>> console.
>
> Where would I find it? (The make output suggests it would be
> in gdb/testsuite/ as that is what the rm command deletes, but
> there is no gdb.log file in that directory.)

It should be in gdb/testsuite/gdb.log, but it looks like it didn't make
it to the disk.

> Is there something I can rm in my build directory that will delete
> all the testsuite stuff and force it to recreate it ? (I would
> prefer not to have to blow away the whole build directory and
> spend hours waiting for gdb to be rebuilt...)

You can try deleting these under $GDB_BUILD_DIR:

gdb/testsuite/site.exp
gdb/testsuite/cache
gdb/testsuite/outputs

In the worst case, you could delete the whole gdb/ directory. You'll
have to rebuild all the gdb files, but at least not bfd, gdbserver,
gdbsupport etc.

-- 
Thiago

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Fri, 30 Jan 2026 at 17:06, Thiago Jung Bauermann
<thiago.bauermann@linaro.org> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> > Is there something I can rm in my build directory that will delete
> > all the testsuite stuff and force it to recreate it ? (I would
> > prefer not to have to blow away the whole build directory and
> > spend hours waiting for gdb to be rebuilt...)
>
> You can try deleting these under $GDB_BUILD_DIR:
>
> gdb/testsuite/site.exp
> gdb/testsuite/cache
> gdb/testsuite/outputs
>
> In the worst case, you could delete the whole gdb/ directory. You'll
> have to rebuild all the gdb files, but at least not bfd, gdbserver,
> gdbsupport etc.

I tried removing all of gdb/testsuite/ and then putting back
the files that 'make' complained were missing (config.status
and Makefile). That seemed to do the trick at least as far
as being able to run the tests now. With my updated QEMU
(which you can find in the new "sme-no-sve-2" in my gitlab repo)
that can now run the tests without making the kernel fall over.
It reports:

# of expected passes            241
# of unexpected failures        37

Is that the same as you see on the fast model, or does this
indicate that I still have more QEMU bugs to track down?
(Peeking into gdb.log, these failures seem to be run-on
failures from the program under test getting a SIGILL
in initialize_zt_state(), so my guess is QEMU is still not
quite right.)

thanks
-- PMM

Re: gdb support for SME-without-SVE ?

[Thiago Jung Bauermann via Gdb]

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

> On Fri, 30 Jan 2026 at 17:06, Thiago Jung Bauermann
> <thiago.bauermann@linaro.org> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>> > Is there something I can rm in my build directory that will delete
>> > all the testsuite stuff and force it to recreate it ? (I would
>> > prefer not to have to blow away the whole build directory and
>> > spend hours waiting for gdb to be rebuilt...)
>>
>> You can try deleting these under $GDB_BUILD_DIR:
>>
>> gdb/testsuite/site.exp
>> gdb/testsuite/cache
>> gdb/testsuite/outputs
>>
>> In the worst case, you could delete the whole gdb/ directory. You'll
>> have to rebuild all the gdb files, but at least not bfd, gdbserver,
>> gdbsupport etc.
>
> I tried removing all of gdb/testsuite/ and then putting back
> the files that 'make' complained were missing (config.status
> and Makefile). That seemed to do the trick at least as far
> as being able to run the tests now.

Great!

> With my updated QEMU
> (which you can find in the new "sme-no-sve-2" in my gitlab repo)
> that can now run the tests without making the kernel fall over.
> It reports:
>
> # of expected passes            241
> # of unexpected failures        37
>
> Is that the same as you see on the fast model, or does this
> indicate that I still have more QEMU bugs to track down?
> (Peeking into gdb.log, these failures seem to be run-on
> failures from the program under test getting a SIGILL
> in initialize_zt_state(), so my guess is QEMU is still not
> quite right.)

Indeed, there seems to be something off with QEMU.
On FVP, all the tests pass:

                === gdb Summary ===

# of expected passes            278

-- 
Thiago

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Fri, 30 Jan 2026 at 18:18, Thiago Jung Bauermann
<thiago.bauermann@linaro.org> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> > With my updated QEMU
> > (which you can find in the new "sme-no-sve-2" in my gitlab repo)
> > that can now run the tests without making the kernel fall over.
> > It reports:
> >
> > # of expected passes            241
> > # of unexpected failures        37
> >
> > Is that the same as you see on the fast model, or does this
> > indicate that I still have more QEMU bugs to track down?
> > (Peeking into gdb.log, these failures seem to be run-on
> > failures from the program under test getting a SIGILL
> > in initialize_zt_state(), so my guess is QEMU is still not
> > quite right.)
>
> Indeed, there seems to be something off with QEMU.
> On FVP, all the tests pass:
>
>                 === gdb Summary ===
>
> # of expected passes            278

Just to check, does your FVP have the SME2p1 feature ?
(Should show up as "sme2p1" in the feature list in /proc/cpuinfo
in the guest.) The SIGILL is happening on the attempt to set ZT0:

  /* Initialize ZT0.  */
  /* ldr zt0, x0 */
  __asm __volatile (".word 0xe11f8000");

because QEMU thinks that EL0 doesn't have access to ZT0.
If your FVP isn't emulating SME2p1 then the test code will
return early before getting to that part of the function.

-- PMM

Re: gdb support for SME-without-SVE ?

[Thiago Jung Bauermann via Gdb]

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

> On Fri, 30 Jan 2026 at 18:18, Thiago Jung Bauermann
> <thiago.bauermann@linaro.org> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>> > With my updated QEMU
>> > (which you can find in the new "sme-no-sve-2" in my gitlab repo)
>> > that can now run the tests without making the kernel fall over.
>> > It reports:
>> >
>> > # of expected passes            241
>> > # of unexpected failures        37
>> >
>> > Is that the same as you see on the fast model, or does this
>> > indicate that I still have more QEMU bugs to track down?
>> > (Peeking into gdb.log, these failures seem to be run-on
>> > failures from the program under test getting a SIGILL
>> > in initialize_zt_state(), so my guess is QEMU is still not
>> > quite right.)
>>
>> Indeed, there seems to be something off with QEMU.
>> On FVP, all the tests pass:
>>
>>                 === gdb Summary ===
>>
>> # of expected passes            278
>
> Just to check, does your FVP have the SME2p1 feature ?
> (Should show up as "sme2p1" in the feature list in /proc/cpuinfo
> in the guest.)

It doesn't. Here's my FVP's feature list:

Features        : fp asimd evtstrm crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop asimddp asimdfhm dit uscat ilrcpc flagm sb paca pacg gcs dcpodp flagm2 frint i8mm bf16 dgh rng bti ecv afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 wfxt ebf16 cssc mops hbc poe lsfe

> The SIGILL is happening on the attempt to set ZT0:
>
>   /* Initialize ZT0.  */
>   /* ldr zt0, x0 */
>   __asm __volatile (".word 0xe11f8000");
>
> because QEMU thinks that EL0 doesn't have access to ZT0.
> If your FVP isn't emulating SME2p1 then the test code will
> return early before getting to that part of the function.

I'm running shrinkwrap using the --overlay option with the following
file:

run:
  params:
    -C cluster0.has_sve : 1
    -C cluster1.has_sve : 1
    -C cluster0.sve.has_sme2 : 0
    -C cluster1.sve.has_sme2 : 0
    -C cluster0.sve.has_sme : 1
    -C cluster1.sve.has_sme : 1
    -C cluster0.sve.has_sve2 : 1
    -C cluster1.sve.has_sve2 : 1
    -C cluster0.sve.sme_only : 1
    -C cluster1.sve.sme_only : 1

The FVP setup was built with:

$ shrinkwrap build --overlay=arch/v9.5.yaml ns-edk2.yaml

if it makes a difference. I'll see if I can try to turn SME2p1 on.

-- 
Thiago

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Fri, 30 Jan 2026 at 18:40, Thiago Jung Bauermann
<thiago.bauermann@linaro.org> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Fri, 30 Jan 2026 at 18:18, Thiago Jung Bauermann
> > <thiago.bauermann@linaro.org> wrote:
> >> Peter Maydell <peter.maydell@linaro.org> writes:
> >> > With my updated QEMU
> >> > (which you can find in the new "sme-no-sve-2" in my gitlab repo)
> >> > that can now run the tests without making the kernel fall over.
> >> > It reports:
> >> >
> >> > # of expected passes            241
> >> > # of unexpected failures        37
> >> >
> >> > Is that the same as you see on the fast model, or does this
> >> > indicate that I still have more QEMU bugs to track down?
> >> > (Peeking into gdb.log, these failures seem to be run-on
> >> > failures from the program under test getting a SIGILL
> >> > in initialize_zt_state(), so my guess is QEMU is still not
> >> > quite right.)
> >>
> >> Indeed, there seems to be something off with QEMU.
> >> On FVP, all the tests pass:
> >>
> >>                 === gdb Summary ===
> >>
> >> # of expected passes            278
> >
> > Just to check, does your FVP have the SME2p1 feature ?
> > (Should show up as "sme2p1" in the feature list in /proc/cpuinfo
> > in the guest.)
>
> It doesn't. Here's my FVP's feature list:
>
> Features        : fp asimd evtstrm crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop asimddp asimdfhm dit uscat ilrcpc flagm sb paca pacg gcs dcpodp flagm2 frint i8mm bf16 dgh rng bti ecv afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 wfxt ebf16 cssc mops hbc poe lsfe

OK. If I nobble QEMU locally to not enable SME2/SME2p1 (which
needs source changes, as there's no command line flag for it)
then I get a complete set of passes:

# of expected passes            278

So possibilities:
 * bug in your test code for the SME2p1 case
 * bug in the kernel's support for SME2p1
 * bug in QEMU's support for SME2p1

-- PMM

Re: gdb support for SME-without-SVE ?

[Thiago Jung Bauermann via Gdb]

Thiago Jung Bauermann <thiago.bauermann@linaro.org> writes:

> Peter Maydell <peter.maydell@linaro.org> writes:
>
>> On Fri, 30 Jan 2026 at 18:18, Thiago Jung Bauermann
>> <thiago.bauermann@linaro.org> wrote:
>>> Peter Maydell <peter.maydell@linaro.org> writes:
>>> > With my updated QEMU
>>> > (which you can find in the new "sme-no-sve-2" in my gitlab repo)
>>> > that can now run the tests without making the kernel fall over.
>>> > It reports:
>>> >
>>> > # of expected passes            241
>>> > # of unexpected failures        37
>>> >
>>> > Is that the same as you see on the fast model, or does this
>>> > indicate that I still have more QEMU bugs to track down?
>>> > (Peeking into gdb.log, these failures seem to be run-on
>>> > failures from the program under test getting a SIGILL
>>> > in initialize_zt_state(), so my guess is QEMU is still not
>>> > quite right.)
>>>
>>> Indeed, there seems to be something off with QEMU.
>>> On FVP, all the tests pass:
>>>
>>>                 === gdb Summary ===
>>>
>>> # of expected passes            278
>>
>> Just to check, does your FVP have the SME2p1 feature ?
>> (Should show up as "sme2p1" in the feature list in /proc/cpuinfo
>> in the guest.)
>
> It doesn't. Here's my FVP's feature list:
>
> Features : fp asimd evtstrm crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc
> dcpop asimddp asimdfhm dit uscat ilrcpc flagm sb paca pacg gcs dcpodp flagm2 frint i8mm
> bf16 dgh rng bti ecv afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32
> wfxt ebf16 cssc mops hbc poe lsfe
>
>> The SIGILL is happening on the attempt to set ZT0:
>>
>>   /* Initialize ZT0.  */
>>   /* ldr zt0, x0 */
>>   __asm __volatile (".word 0xe11f8000");
>>
>> because QEMU thinks that EL0 doesn't have access to ZT0.
>> If your FVP isn't emulating SME2p1 then the test code will
>> return early before getting to that part of the function.
>
> I'm running shrinkwrap using the --overlay option with the following
> file:
>
> run:
>   params:
>     -C cluster0.has_sve : 1
>     -C cluster1.has_sve : 1
>     -C cluster0.sve.has_sme2 : 0
>     -C cluster1.sve.has_sme2 : 0
>     -C cluster0.sve.has_sme : 1
>     -C cluster1.sve.has_sme : 1
>     -C cluster0.sve.has_sve2 : 1
>     -C cluster1.sve.has_sve2 : 1
>     -C cluster0.sve.sme_only : 1
>     -C cluster1.sve.sme_only : 1

I was able to enable SME2p1 by adding these options:

    -C cluster0.sve.sme2_version : 1
    -C cluster1.sve.sme2_version : 1

Now my features list shows sme2p1:

Features        : fp asimd evtstrm crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop asimddp asimdfhm dit uscat ilrcpc flagm sb paca pacg gcs dcpodp flagm2 frint i8mm bf16 dgh rng bti ecv afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 wfxt ebf16 cssc sme2 sme2p1 smei16i32 smebi32i32 mops hbc poe lsfe

I still get only passes in the testcase, but more tests were run now:

                === gdb Summary ===

# of expected passes            286

The sme2_version option goes all the way to SME2p3, but I didn't try
that one.

-- 
Thiago

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Fri, 30 Jan 2026 at 18:59, Thiago Jung Bauermann
<thiago.bauermann@linaro.org> wrote:
> I was able to enable SME2p1 by adding these options:
>
>     -C cluster0.sve.sme2_version : 1
>     -C cluster1.sve.sme2_version : 1
>
> Now my features list shows sme2p1:
>
> Features        : fp asimd evtstrm crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop asimddp asimdfhm dit uscat ilrcpc flagm sb paca pacg gcs dcpodp flagm2 frint i8mm bf16 dgh rng bti ecv afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 wfxt ebf16 cssc sme2 sme2p1 smei16i32 smebi32i32 mops hbc poe lsfe
>
> I still get only passes in the testcase, but more tests were run now:
>
>                 === gdb Summary ===
>
> # of expected passes            286
>
> The sme2_version option goes all the way to SME2p3, but I didn't try
> that one.

Great -- this must be a QEMU issue.

-- PMM

Re: gdb support for SME-without-SVE ?

[Thiago Jung Bauermann via Gdb]

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

> On Fri, 30 Jan 2026 at 18:59, Thiago Jung Bauermann
> <thiago.bauermann@linaro.org> wrote:
>> I was able to enable SME2p1 by adding these options:
>>
>>     -C cluster0.sve.sme2_version : 1
>>     -C cluster1.sve.sme2_version : 1
>>
>> Now my features list shows sme2p1:
>>
>> Features        : fp asimd evtstrm crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop asimddp asimdfhm dit uscat ilrcpc flagm sb paca pacg gcs dcpodp flagm2 frint i8mm bf16 dgh rng bti ecv afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 wfxt ebf16 cssc sme2 sme2p1 smei16i32 smebi32i32 mops hbc poe lsfe
>>
>> I still get only passes in the testcase, but more tests were run now:
>>
>>                 === gdb Summary ===
>>
>> # of expected passes            286
>>
>> The sme2_version option goes all the way to SME2p3, but I didn't try
>> that one.
>
> Great -- this must be a QEMU issue.

Ok. Let me know if you want me to try anything else.

-- 
Thiago

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Fri, 30 Jan 2026 at 19:01, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Fri, 30 Jan 2026 at 18:59, Thiago Jung Bauermann
> <thiago.bauermann@linaro.org> wrote:
> > I was able to enable SME2p1 by adding these options:
> >
> >     -C cluster0.sve.sme2_version : 1
> >     -C cluster1.sve.sme2_version : 1
> >
> > Now my features list shows sme2p1:
> >
> > Features        : fp asimd evtstrm crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop asimddp asimdfhm dit uscat ilrcpc flagm sb paca pacg gcs dcpodp flagm2 frint i8mm bf16 dgh rng bti ecv afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 wfxt ebf16 cssc sme2 sme2p1 smei16i32 smebi32i32 mops hbc poe lsfe
> >
> > I still get only passes in the testcase, but more tests were run now:
> >
> >                 === gdb Summary ===
> >
> > # of expected passes            286
> >
> > The sme2_version option goes all the way to SME2p3, but I didn't try
> > that one.
>
> Great -- this must be a QEMU issue.

I figured out what happens here -- if you use "-cpu max,sme=on"
a QEMU bug means this messes up the ID register value passed to the
guest (it forces the SME field in the register to 1, downgrading
it from SME2 to a weird thing that confuses the guest kernel).
If you stick to "-cpu max,sve=off" with no 'sme=on' part (relying
on the 'max' default being "SME2 is present") then you can get the
full set of 286 passes.

I'll fix the QEMU handling of the option, but in the meantime
you can use that as a workaround if you want.

thanks
-- PMM

Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb]

On Mon, 2 Feb 2026 at 11:01, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Fri, 30 Jan 2026 at 19:01, Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> > On Fri, 30 Jan 2026 at 18:59, Thiago Jung Bauermann
> > <thiago.bauermann@linaro.org> wrote:
> > > I was able to enable SME2p1 by adding these options:
> > >
> > >     -C cluster0.sve.sme2_version : 1
> > >     -C cluster1.sve.sme2_version : 1
> > >
> > > Now my features list shows sme2p1:
> > >
> > > Features        : fp asimd evtstrm crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop asimddp asimdfhm dit uscat ilrcpc flagm sb paca pacg gcs dcpodp flagm2 frint i8mm bf16 dgh rng bti ecv afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 wfxt ebf16 cssc sme2 sme2p1 smei16i32 smebi32i32 mops hbc poe lsfe
> > >
> > > I still get only passes in the testcase, but more tests were run now:
> > >
> > >                 === gdb Summary ===
> > >
> > > # of expected passes            286
> > >
> > > The sme2_version option goes all the way to SME2p3, but I didn't try
> > > that one.
> >
> > Great -- this must be a QEMU issue.
>
> I figured out what happens here -- if you use "-cpu max,sme=on"
> a QEMU bug means this messes up the ID register value passed to the
> guest (it forces the SME field in the register to 1, downgrading
> it from SME2 to a weird thing that confuses the guest kernel).
> If you stick to "-cpu max,sve=off" with no 'sme=on' part (relying
> on the 'max' default being "SME2 is present") then you can get the
> full set of 286 passes.
>
> I'll fix the QEMU handling of the option, but in the meantime
> you can use that as a workaround if you want.

...and I have now pushed an sme-no-sve-3 branch to my gitlab
QEMU repo which fixes the sme=on option handling and a few other
minor things:

https://gitlab.com/pm215/qemu/-/commits/sme-no-sve-3

-- PMM

Re: gdb support for SME-without-SVE ?

[Thiago Jung Bauermann via Gdb]

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

> On Mon, 2 Feb 2026 at 11:01, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On Fri, 30 Jan 2026 at 19:01, Peter Maydell <peter.maydell@linaro.org> wrote:
>> >
>> > On Fri, 30 Jan 2026 at 18:59, Thiago Jung Bauermann
>> > <thiago.bauermann@linaro.org> wrote:
>> > > I was able to enable SME2p1 by adding these options:
>> > >
>> > >     -C cluster0.sve.sme2_version : 1
>> > >     -C cluster1.sve.sme2_version : 1
>> > >
>> > > Now my features list shows sme2p1:
>> > >
>> > > Features        : fp asimd evtstrm crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop asimddp asimdfhm dit uscat ilrcpc flagm sb paca pacg gcs dcpodp flagm2 frint i8mm bf16 dgh rng bti ecv afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 wfxt ebf16 cssc sme2 sme2p1 smei16i32 smebi32i32 mops hbc poe lsfe
>> > >
>> > > I still get only passes in the testcase, but more tests were run now:
>> > >
>> > >                 === gdb Summary ===
>> > >
>> > > # of expected passes            286
>> > >
>> > > The sme2_version option goes all the way to SME2p3, but I didn't try
>> > > that one.
>> >
>> > Great -- this must be a QEMU issue.
>>
>> I figured out what happens here -- if you use "-cpu max,sme=on"
>> a QEMU bug means this messes up the ID register value passed to the
>> guest (it forces the SME field in the register to 1, downgrading
>> it from SME2 to a weird thing that confuses the guest kernel).
>> If you stick to "-cpu max,sve=off" with no 'sme=on' part (relying
>> on the 'max' default being "SME2 is present") then you can get the
>> full set of 286 passes.
>>
>> I'll fix the QEMU handling of the option, but in the meantime
>> you can use that as a workaround if you want.
>
> ...and I have now pushed an sme-no-sve-3 branch to my gitlab
> QEMU repo which fixes the sme=on option handling and a few other
> minor things:
>
> https://gitlab.com/pm215/qemu/-/commits/sme-no-sve-3

Great! Now the results from the GDB SME tests (running all
aarch64-sme*.exp tests, not only the sanity one) match what I get with
the FVP. I get some failures, but they are problems with my GDB branch.

This branch works fine for me.

-- 
Thiago

Re: gdb support for SME-without-SVE ?

[Luis via Gdb]

Maybe late to the party, but "make clean" in gdb/testsuite or just
re-running gdb/testsuite/configure should clean things up.

If you have a gdb executable, you can point the testsuite to it via
RUNTESTFLAGS. That way you won't need to rebuild gdb etc.

I think gdb/testsuite/ has a readme with some helpful info.

On Fri, Jan 30, 2026, 17:17 Peter Maydell <peter.maydell@linaro.org> wrote:

> On Fri, 30 Jan 2026 at 17:06, Thiago Jung Bauermann
> <thiago.bauermann@linaro.org> wrote:
> > Peter Maydell <peter.maydell@linaro.org> writes:
> > > Is there something I can rm in my build directory that will delete
> > > all the testsuite stuff and force it to recreate it ? (I would
> > > prefer not to have to blow away the whole build directory and
> > > spend hours waiting for gdb to be rebuilt...)
> >
> > You can try deleting these under $GDB_BUILD_DIR:
> >
> > gdb/testsuite/site.exp
> > gdb/testsuite/cache
> > gdb/testsuite/outputs
> >
> > In the worst case, you could delete the whole gdb/ directory. You'll
> > have to rebuild all the gdb files, but at least not bfd, gdbserver,
> > gdbsupport etc.
>
> I tried removing all of gdb/testsuite/ and then putting back
> the files that 'make' complained were missing (config.status
> and Makefile). That seemed to do the trick at least as far
> as being able to run the tests now. With my updated QEMU
> (which you can find in the new "sme-no-sve-2" in my gitlab repo)
> that can now run the tests without making the kernel fall over.
> It reports:
>
> # of expected passes            241
> # of unexpected failures        37
>
> Is that the same as you see on the fast model, or does this
> indicate that I still have more QEMU bugs to track down?
> (Peeking into gdb.log, these failures seem to be run-on
> failures from the program under test getting a SIGILL
> in initialize_zt_state(), so my guess is QEMU is still not
> quite right.)
>
> thanks
> -- PMM
>

Re: gdb support for SME-without-SVE ?

[Andrew Pinski via Gdb]

On Tue, Jan 27, 2026 at 3:33 AM Peter Maydell via Gdb
<gdb@sourceware.org> wrote:
>
> Hi: is GDB for Arm intended to support configurations where the target
> CPU has SME but not SVE?
>
> We're just implementing support for that in QEMU for using SME
> with the hvf hypervisor accelerator on macos systems, but when
> we tried connecting gdb to QEMU gdb crashed:
>
>   (gdb) target remote localhost:1234
>   Remote debugging using localhost:1234
>   ../../gdb/aarch64-tdep.c:3068: internal-error:
> aarch64_pseudo_register_type: bad register number 160
>   A problem internal to GDB has been detected,
>   further debugging may prove unreliable.
>   Fatal signal: Abort trap: 6
>
> https://lore.kernel.org/qemu-devel/CAAjaMXZLG2aBtStRhyvmdENj1Z+Mx05BmDgyYUoYrc_ZnHwyVQ@mail.gmail.com/
>
> Is this a known missing feature in GDB, or is it a config that's
> supposed to work but we've got the XML register description wrong
> somehow?
>
> It looks from the aarch64-tdep.c code like perhaps GDB assumes
> that the Vn vector registers only exist with SVE, but they also
> exist in SME-only CPUs.

I think the support is not there yet because at one point
(non-streaming) SVE was a requirement for SME at least for software
(it was also the recommended way from Arm too) but things changed when
Apple decided to implement their cores without (non-streaming) SVE.
GCC support for this is in review
(https://patchwork.sourceware.org/project/gcc/list/?series=56024). I
don't know if the Arm folks have started work on supporting this for
gdb yet.
Also I don't think GCC support will be included until GCC 17 either.

Thanks,
Andrew Pinski

>
> thanks
> -- PMM

Re: gdb support for SME-without-SVE ?

[Luis via Gdb]

On Tue, Jan 27, 2026, 11:32 Peter Maydell <peter.maydell@linaro.org> wrote:

> Hi: is GDB for Arm intended to support configurations where the target
> CPU has SME but not SVE?
>

Technically yes, but I haven't exercised that scenario that much. I'd
assume it broken.

At the time the prospect was to have both SVE and SME. But that changed a
bit over time and nobody enabled that in gdb.


> We're just implementing support for that in QEMU for using SME
> with the hvf hypervisor accelerator on macos systems, but when
> we tried connecting gdb to QEMU gdb crashed:
>
>   (gdb) target remote localhost:1234
>   Remote debugging using localhost:1234
>   ../../gdb/aarch64-tdep.c:3068: internal-error:
> aarch64_pseudo_register_type: bad register number 160
>   A problem internal to GDB has been detected,
>   further debugging may prove unreliable.
>   Fatal signal: Abort trap: 6
>
>
> https://lore.kernel.org/qemu-devel/CAAjaMXZLG2aBtStRhyvmdENj1Z+Mx05BmDgyYUoYrc_ZnHwyVQ@mail.gmail.com/
>
> Is this a known missing feature in GDB, or is it a config that's
> supposed to work but we've got the XML register description wrong
> somehow?
>

I'd say missing. And apparently gdb is not well guarded against it.


> It looks from the aarch64-tdep.c code like perhaps GDB assumes
> that the Vn vector registers only exist with SVE, but they also
> exist in SME-only CPUs.
>
> thanks
> -- PMM
>