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/

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 :-()


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,

P.S.: Michael's table is very revealing. See, for instance,

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]