Re: [PATCH] use "verbose" for notification of not running a test

[Andrew Cagney <cagney@gnu.org>]

>> gdb.arch/altivec-abi.exp:    verbose "Skipping altivec abi tests."
>> gdb.arch/altivec-regs.exp:    verbose "Skipping altivec register tests."
>> gdb.arch/e500-abi.exp:    verbose "Skipping e500 abi tests."
>> gdb.arch/e500-regs.exp:    verbose "Skipping e500 register tests."
>> gdb.arch/gdb1291.exp:    verbose "Skipping SH backtrace tests."
>> gdb.arch/gdb1431.exp:    verbose "Skipping SH backtrace tests."
>> gdb.arch/i386-prologue.exp:    verbose "Skipping i386 prologue tests."
>> gdb.arch/i386-unwind.exp:    verbose "Skipping i386 unwinder tests."
> 
> 
> Hmmm.  These are all conditioned on target architecture.
> 
> My first reaction is that it's good to have arch-specific tests.
> It would be silly to pretend that gdb has the same features on all
> architectures.  It's a debugger, not a web server or a text editor!
> 
> My second reaction is that when I run an sh-*-* test on native
> i686-pc-linux-gnu, I don't need to see an UNSUPPORTED about it.
> 
> So the existing "verbose ... / return" works for me.
> 
> 
>> gdb.base/a2-run.exp:    verbose "Skipping a2-run.exp because of noargs."
> 
> 
> Yes, I think this is a good place for UNSUPPORTED.
> 
> "noargs" is either a limitation of the test environment or of the
> toolchain.  If it's a limitation of the test environment, I think
> that UNSUPPORTED matches it.  If it's a limitation of the toolchain,
> then it's actually a bit of a cheat to set "noargs", but UNSUPPORTED
> would not be too bad.
> 
> A casual look at dejagnu/baseboards.exp and "noargs" makes me think
> that "noargs" is generally a property of the test board, not a
> property of the toolchain.
> 
> The dejagnu doco says:
> 
>   UNSUPPORTED
>   A test depends on a conditionally available feature that does not
>   exist (in the configured testing environment).  For example, you can
>   use this outcome to report on a test case that does not work on a
>   particular target because its operating system support does not
>   include a required subroutine.
> 
> To me, the things in gdb.arch are not "conditionally available" on
> non-matching targets; they are just plain unavailable.
> 
> And if the limit is in the toolchain rather than the testing
> environment, it is really a FAIL, not an UNSUPPORTED.  UNIMPLEMENTED
> would be more accurate but there is no such word, so I'm not too
> hurt by fudging UNSUPPORTED to mean "unsupported by the toolchain"
> as well as "unsupported by the test environment" from time to time.

Unimplemented is, in a sense, equivalent to KFAIL.  It fails because 
someone hasn't fixed it.

Here, though, its fuzzy.

For some baseboards it really can't be implemented - cases where the 
"osabi" (I use the term loosely given its a baseboard) doesn't define 
the the mechanism for passing argv to the starting program for others it 
may be possible, just that no one is motivated to do it.

However, UNSUPPORTED may be sufficient.  What ever :-)

Andrew

> What do other people think?
> 
> Michael C
>