Re: gdb support for SME-without-SVE ?

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 <[email protected]> wrote:

> On Fri, 30 Jan 2026 at 17:06, Thiago Jung Bauermann
> <[email protected]> wrote:
> > Peter Maydell <[email protected]> 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
>