From: Luis via Gdb <gdb@sourceware.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Thiago Jung Bauermann <thiago.bauermann@linaro.org>,
gdb@sourceware.org,
Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Subject: Re: gdb support for SME-without-SVE ?
Date: Fri, 30 Jan 2026 18:24:07 +0000 [thread overview]
Message-ID: <CANnS9rt-10fJ_53qAya25iMNpYe-NQ68omO4b_EuyBDwWxeKNw@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA9S3qJSj8q+On+e6TrU+5MyhVpZ0Yvs0r4Py4Zre95ykw@mail.gmail.com>
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
>
next prev parent reply other threads:[~2026-01-30 18:29 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 11:31 Peter Maydell via Gdb
2026-01-27 14:21 ` Simon Marchi via Gdb
2026-01-27 14:47 ` Peter Maydell via Gdb
2026-01-27 14:57 ` Simon Marchi via Gdb
2026-01-27 21:23 ` Peter Maydell via Gdb
2026-01-27 21:28 ` Simon Marchi via Gdb
2026-01-28 1:07 ` Luis via Gdb
2026-01-28 4:23 ` Thiago Jung Bauermann via Gdb
2026-01-28 8:02 ` Luis via Gdb
2026-01-28 16:20 ` Peter Maydell via Gdb
2026-01-29 4:12 ` Thiago Jung Bauermann via Gdb
2026-01-29 9:10 ` Peter Maydell via Gdb
2026-01-29 11:34 ` Peter Maydell via Gdb
2026-01-30 4:28 ` Thiago Jung Bauermann via Gdb
2026-01-30 9:41 ` Peter Maydell via Gdb
2026-01-30 12:29 ` Peter Maydell via Gdb
2026-01-30 16:16 ` Thiago Jung Bauermann via Gdb
2026-01-30 16:29 ` Peter Maydell via Gdb
2026-01-30 17:06 ` Thiago Jung Bauermann via Gdb
2026-01-30 17:17 ` Peter Maydell via Gdb
2026-01-30 18:18 ` Thiago Jung Bauermann via Gdb
2026-01-30 18:34 ` Peter Maydell via Gdb
2026-01-30 18:40 ` Thiago Jung Bauermann via Gdb
2026-01-30 18:59 ` Peter Maydell via Gdb
2026-01-30 18:59 ` Thiago Jung Bauermann via Gdb
2026-01-30 19:01 ` Peter Maydell via Gdb
2026-01-30 19:03 ` Thiago Jung Bauermann via Gdb
2026-02-02 11:01 ` Peter Maydell via Gdb
2026-02-02 14:06 ` Peter Maydell via Gdb
2026-02-02 20:43 ` Thiago Jung Bauermann via Gdb
2026-01-30 18:24 ` Luis via Gdb [this message]
2026-01-27 21:29 ` Andrew Pinski via Gdb
2026-01-28 0:42 ` Luis via Gdb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANnS9rt-10fJ_53qAya25iMNpYe-NQ68omO4b_EuyBDwWxeKNw@mail.gmail.com \
--to=gdb@sourceware.org \
--cc=luis.machado.foss@gmail.com \
--cc=manos.pitsidianakis@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=thiago.bauermann@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox