RE: [builder] gdb_check_step: remove gdb.gdb/selftest.exp

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