On Thu, 24 Oct 2002 14:41:05 -0400, Andrew Cagney <ac131313@xxxxxxxxxx> said:
GDB's testsuite is known to be full of xfails that are really kfails
or testsuite bugs. Rather than try to audit each xfail in turn, the
proposal as been to rip out all the xfails (creating a clean slate)
and start marking up the tests from scratch - two steps forward but
first one step back.
Can you give me a little guidance here? Elena recently made the
suggestion that I should add tests to the testsuite for namespace
stuff, even before I've modified GDB to handle that. That sounded
sensible to me, so I added that to a branch, and marked them all as
xfail.
I think Elena mentioned KFAIL. Any way, that is want you want to use -
you'll need to bug report any failures though.
I suspect I was wrong about that, though I'm not sure about the
subtleties of what xfail is actually supposed to mean. I was thinking
I should go and change them to kfail, but now I'm not confident that I
know the intended semantics of that, either. Is kfail only allowed
for tests with a PR associated to them? Admittedly, in a branch,
xfail and kfail mean whatever I want them to mean, I suppose, and I'm
not going to try to get those tests added to the mainline unless I can
bring along much of the code that cause them to pass instead of fail.
A fairly good definition is:
KFAIL == bug, in GDB, something to fix.
XFAIL == bug, not in GDB (kernel, debug info, linker, ...), something to
ignore.
I guess I don't see the point in removing xfails from the testsuite:
it's useful information, it doesn't make regression testing any harder
(there, the main culprit is the !@#%# schedlock test), so why throw
that away? If xfail has the wrong meaning, then change it to kfail;
if kfail also has the wrong meaning, then change the meaning of kfail.
People have been XFAILing bugs in GDB. That is simply wrong.
Andrew
|
