[patch/rfc] Remove all setup_xfail's from testsuite/gdb.mi/

[Fernando Nasser]

Andrew Cagney wrote:
> Fernando,
> 
> What is the resolution of this thread?
> http://sources.redhat.com/ml/gdb-patches/2002-10/msg00508.html
> (you'll probably want to read all of it :-)
> (I'm now going back and emptying my mail box :-()
> 
> Andrew
> 

Hi Andrew,

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

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

As I said, this is just a brainstorm.  Please comment.

Regards to all,
Fernando

P.S.: Michael's table is very revealing.  See, for instance,
    http://www.shout.net/~mec/sunday/2003-01-09/Counts.html




-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9