This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa:testsuite} Overhaul sizeof.exp

Daniel Jacobowitz wrote:
> On Wed, Feb 20, 2002 at 11:15:44AM -0500, Fernando Nasser wrote:
> > Andrew Cagney wrote:
> > >
> > > The XFAIL policy is different to GDB.  GDB interprets XFAILs to mean not
> > > supported due to something outside of GDB's control.  Not this is a bug
> > > but we're not fixing it at present.
> > >
> >
> > Gdb follows the Dejagnu intended meaning for XFAILs.
> Really?  I think you mean that GCC does.  From the DejaGNU manual:
>      A test failed, but it was expected to fail.  This result indicates
>      no change in a known bug.  If a test fails because the operating
>      system where the test runs lacks some facility required by the
>      test, the outcome is `UNSUPPORTED' instead.
> XFAILS are intended to represent known bugs, and we should be using
> UNSUPPORTED more heavily.

"lacks some facility required by the test" means something that the OS
run environment does not support and will never support because it is
just not the way things are done on that type of system.

We should _not_ be using UNSUPPORTED at large.

"This result indicates no change in a known bug."  This sentence is too
ambiguous.  I guess you can twist it in any way you want.

The GDB meaning for "A test failed, but it was expected to fail", for
years now, has been that there is a problem in the OS/runtime
that will cause it to fail.  That is why it is normally marked as xfail
for some specific target triplet.

I guess the reasoning was that nobody normally "expects" something to
we expect something to work.  We only expect it to fail when there is
beyond our control that will cause it to fail and that we hope will be
(and things suddenly become XPASSes).

Anyway, who has the right interpretation or not is irrelevant.  We do
two distinct situations and it would be nice to be able to handle them

Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]