From: Carl Love <cel@us.ibm.com>
To: Luis Machado <luis.machado@arm.com>,
Mark Wielaard <mark@klomp.org>,
Will Schmidt <will_schmidt@vnet.ibm.com>
Cc: gdb@sourceware.org, buildbot@sourceware.org
Subject: RE: [builder] gdb_check_step: remove gdb.gdb/selftest.exp
Date: Fri, 10 Jun 2022 08:54:00 -0700 [thread overview]
Message-ID: <4649417b632758c6822214b19f04ce70146c43cb.camel@us.ibm.com> (raw)
In-Reply-To: <85fa6e2d-caf5-8afe-a7ec-40cc62ff347a@arm.com>
On Fri, 2022-06-10 at 11:58 +0100, Luis Machado wrote:
> On 6/10/22 11:50, Mark Wielaard wrote:
> > Hi,
> >
> > On Fri, 2022-06-10 at 01:21 +0200, Mark Wielaard wrote:
> > > On Fri, Jun 10, 2022 at 01:09:19AM +0200, Mark Wielaard wrote:
> > > > On Thu, Jun 09, 2022 at 10:37:58AM +0100, Luis Machado wrote:
> > > > > I always use gdb.base/break.exp as a good smoke test. If that
> > > > > one
> > > > > fails, then things
> > > > > are really broken.
> > > > >
> > > > > I think gdb.base/break*.exp should make a good smoke test
> > > > > list.
> > > > > We just need to exclude
> > > > > gdb.base/break-interp.exp, which is problematic on some
> > > > > targets.
Trying to to understand how you are running the test. I think you are
running these as remote tests, i.e. machine A requests that a remote
machine B run the test via gdbserver, correct?
I tried running the tests naitively, i.e. on a Power 10 RHEL 9 system
I ran:
make check RUNTESTFLAGS='GDB=/home/carll/bin/gdb gdb.base/break-
interp.exp '
The gdb summary is:
=== gdb Summary ===
# of expected passes 702
# of expected failures 20
> > > >
> > > > It never is just easy is it? :) You are right, I saw break-
> > > > interp.exp
> > > > fail... I tried to come up with a regexp but gave up given
> > > > that it
> > > > has to go throug python first and then we don't know whether
> > > > the
> > > > worker uses bash as /bin/sh so I just added them all (exclusing
> > > > break-interp.exp) as a list.
> > >
> > > Sigh, sorry, looks like gdb.base/break-unload-file.exp also
> > > sometimes
> > > fails.
> > > I have removed from the list. Hopefully the remaining list does
> > > actually pass.
I ran gdb.base/break-unload-file.exp on the same Power 10 RHEL 9
system.
make check RUNTESTFLAGS='GDB=/home/carll/bin/gdb gdb.base/break-unload-
file.exp '
The gdb summary is:
=== gdb Summary ===
# of expected passes 36
So it doesn't appear the tests are fundamentally broken.
We have only played around with running the gdb testsuite remotely a
little. Specifically, we were working on documenting how it is done.
We see a number of additional issues running remotely versus natively
but at this point have not had the time/bandwidth to dig into them
> >
> > And it didn't :{
> >
>
> Yeah. As expected, the GDB testsuite is a bit delicate when you start
> dealing with
> multiple architectures and modes. But I think this is good progress
> already.
>
> > Both debian-ppc64 and fedora-ppc64le failed (UNRESOLVED)
> > gdb.base/break-idempotent.exp under both native-gdbserver and
> > native-
> > extended-gdbserver
Running that test natively, i.e.
make check RUNTESTFLAGS='GDB=/home/carll/bin/gdb gdb.base/break-
idempotent.exp '
generates a number of errors:
ERROR: breakpoints not deleted
ERROR: no fileid for ltcd97-lp2
ERROR: Couldn't send delete breakpoints to GDB.
ERROR: can't read "gdb_spawn_id": no such variable
while executing
"expect {
-i 1000 -timeout 100
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_internal_erro..."
("uplevel" body line 1)
invoked from within
"uplevel $body" TCL READ VARNAME can't read "gdb_spa
The gdb summary is:
=== gdb Summary ===
# of expected passes 35
# of unresolved testcases 3
> > https://builder.sourceware.org/buildbot/#builders/76/builds/446
> > https://builder.sourceware.org/buildbot/#builders/85/builds/294
>
> Those might be genuine issues. I'm cc-ing Carl and Will so they can
> chime in.
>
Need to work on getting this one fixed for a native run before worrying
about running it remotely.
I will add this to the list of gdb issues that needs work.
Carl
next prev parent reply other threads:[~2022-06-10 15:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-08 18:51 Mark Wielaard
2022-06-09 9:37 ` Luis Machado
2022-06-09 23:09 ` Mark Wielaard
2022-06-09 23:21 ` Mark Wielaard
2022-06-10 10:50 ` Mark Wielaard
2022-06-10 10:58 ` Luis Machado
2022-06-10 15:17 ` will schmidt
2022-06-10 15:54 ` Carl Love [this message]
2022-06-10 19:11 ` Mark Wielaard
2022-06-10 20:11 ` Carl Love
2022-06-10 22:23 ` Frank Ch. Eigler
2022-06-29 15:58 ` Carl Love
2022-06-29 22:42 ` Mark Wielaard
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=4649417b632758c6822214b19f04ce70146c43cb.camel@us.ibm.com \
--to=cel@us.ibm.com \
--cc=buildbot@sourceware.org \
--cc=gdb@sourceware.org \
--cc=luis.machado@arm.com \
--cc=mark@klomp.org \
--cc=will_schmidt@vnet.ibm.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).