This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa/testsuite/mi] Recognize a few incorrect outputs
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [rfa/testsuite/mi] Recognize a few incorrect outputs
- From: Daniel Jacobowitz <drow at mvista dot com>
- Date: Fri, 28 Sep 2001 16:38:42 -0400
- Cc: fnasser at cygnus dot com, gdb-patches at sources dot redhat dot com
- References: <20010928151616.A14106@nevyn.them.org> <3BB4DEBB.1020906@cygnus.com>
On Fri, Sep 28, 2001 at 04:34:03PM -0400, Andrew Cagney wrote:
> > <gripe>
> > A lot of GDB tests seem to be written with only pass and timeout
> > alternatives, or only with overly-specialized fails. The hypocrite-alert
> > readers of this message will note that I'm guilty of the same thing; this is
> > Just Enough to make them catch a few errors I could think of, not enough to
> > recognize completely wrong output. Someday, someone more motivated than I
> > should clean this up.
> > </gripe>
>
> For the MI, this is a pretty obvious fix. I've been doing the same
> thing my self (when I noticed it). One suggestion, can you make that
> fail expression less strict so that it picks. Something like:
>
> <correct-output> (gdb) <more-output> (gdb)
> pass
>
> .* (gdb) .* (gdb)
> fail
>
> timeout
> fail
>
> alternatively (hmm, better?), keep the expression as you have it but add
> a comment in paren vis:
>
> fail "continue to incr_a (compiler bug info is wrong)"
Can we do that? I was under the impression that "(timeout)" was
special. If we can, I'll add both cases - for the wrong debug info and
for some unknown failing output. I'm tempted to mark such tests XFAIL
if we can obviously detect that the compiler is at fault; admittedly,
the test isn't perfect, but it's still better than the current state of
affairs...
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer