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: [patch/rfc] Remove all setup_xfail's from testsuite/gdb.mi/

Michael Elizabeth Chastain wrote:
I agree with Fernando that it's okay to tie every XFAIL to a gdb PR
and turn it into a KFAIL (at least, I think he is saying that).


Let's take a specific case.  gdb.base/constvars.exp has a lot of
tests such as "const char * foo ; ptype foo".  With gcc 2.95.3/stabs+,
the "ptype" prints "char * foo".  This happens because gcc 2.95.3/stabs+
does not put any const information in the stabs.  This is probably never
going to get fixed in the gcc 2 series.

That is a true XFAIL, but it should be conditional to version 2 compilers and stabs, so that it does not show as XPASS everywhere else.

Now the real problem comes to light.  'K' and 'X' are really orthogonal.
'K' means that we know about the problem, and 'X' means that it is
a problem in an external tool, and these two things are separate.
But we made them an either/or, so we have to choose.

I'd rather have this become a KFAIL with reference to a gdb PR.  Then
the gdb PR can say that this incorrect behavior happens, but it's not
gdb's fault.  The gdb PR should refer to a gcc PR or other external PR.
And then we can't close the gdb PR until gcc revives gcc 2.X development
or gdb drop supports for gcc 2.X.

We could add another PR state for these kind of PR's, or we could
just use the 'suspended' state.

The Dejagnu community will kill me if I come out with yet another type of failure ;-) The problem is that the international standard don't even recognize these extensions we've added (XFAIL and KFAIL), although I think they are really important and your weekely reports prove that.

From the gdb user's point of view, a bug is a bug.  A gdb user can do
the same thing as the test suite and then file a PR: 'gdb fails to
print 'const' for const types'.

Yes, but we have little control over what we call XFAIL cases. But you have a good point that they deserve some user documentation as much as the KFAILs do.

Please see my reply to Daniel's message.

Fernando Nasser
Red Hat - Toronto 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]