This is the mail archive of the
mailing list for the GDB project.
Re: [patch/rfc] Remove all setup_xfail's from testsuite/gdb.mi/
- From: Fernando Nasser <fnasser at redhat dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 15 Jan 2003 12:25:45 -0500
- Subject: Re: [patch/rfc] Remove all setup_xfail's from testsuite/gdb.mi/
- Organization: Red Hat , Inc. - Toronto
- References: <3DB83EC1.email@example.com> <3E25845A.firstname.lastname@example.org>
Andrew Cagney wrote:
What is the resolution of this thread?
(you'll probably want to read all of it :-)
(I'm now going back and emptying my mail box :-()
I am just starting to think about this, so bear with me while I think aloud a
little bit :-) There are lots of good points made on that discussion and I
don't think this is a clear cut yet or no, lets vote, or anything like that. I
am trying to see if I can collect all good suggestions and propose a course of
It seems that a widespread concern is not to through the baby with the water.
On the other hand there is the feeling that we do not act now nothing will ever
happen. And we all agree that many xfails were added incorrectly.
Independently of the "big plan", one thing is clear. If you know that a xfail
is incorrect (I mean, know for good), then it should be ripped off. But read on...
Maybe we may not be in full agreement here, but I think it would be nice to
enter a bug report even if does not include a full analysis -- that should come
eventually. Something like "something is wrong with the '--xxx-yyy' command
output" may eventually cause someone to look into it. And you can make the
xfail a kfail in that case, which is much better. But I know it is much more
work than just removing the xfail and letting the test fail -- you would have to
enter 28 bug reports just for the MI tests. Still sounds like a better approach
to me, but there is no consensus on it.
W.r.t. the non-MI xfails, looking at Michael's reports, more than half of them
seem to be related to stabs problems in different gcc versions. They should be
conditional to stabs and the compiler version and are not, but otherwise they
are valid xfails (by definition). There are a couple of XPASSes that are always
there, so we have at least two obsolete XFAILs that we can get rid off (just
look at a dwarf-2 test result -- those 2).
The remaining ones are 71 (take or add one or two). We can use the gcc 3.2.1
results on RHL 8.0 to determine which ones they are. If seven of us (the
magnificent seven? :-) agree to look into 10 of those each and enter even a
basic bug report we can kfail them all and use the bug database to track the
As I said, this is just a brainstorm. Please comment.
Regards to all,
P.S.: Michael's table is very revealing. See, for instance,
Red Hat - Toronto E-Mail: email@example.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9