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

[mec.gnu@mindspring.com (Michael Elizabeth Chastain)]

> 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.

What do other people think?

Michael C