From: Pedro Alves <palves@redhat.com>
To: Tom de Vries <tdevries@suse.de>, gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: Re: [RFC][gdb/testsuite] Add gdbfail/envfail aliases for kfail/xfail
Date: Sat, 20 Jun 2020 16:46:14 +0100 [thread overview]
Message-ID: <6ac2b328-76ce-1c0e-8b1d-bd818a0caeae@redhat.com> (raw)
In-Reply-To: <20200430064319.GA24688@delia>
On 4/30/20 7:43 AM, Tom de Vries wrote:
> Hi,
>
> The difference between an xfail and a kfail (in the context of gdb testing) is
> that:
> - a kfail marks a problem in gdb
> - an xfail marks a problem in the environment (compiler, libc, kernel)
>
> However, this difference is not immediately obvious from the contrast between
> "known" and "expected".
I memorized the the X in xfail as "external", not "expected".
So I always think of them as "known" vs "external", which makes the
difference much more obvious, IMO.
I propose that the documentation references the "external" mnemonic to help.
KFAIL and XFAIL are documented in testsuite/README:
XFAIL
Short for "expected failure", this indicates a known problem with the
environment. This could include limitations of the operating system,
compiler version, and other components.
Maybe some new entry on KFAIL/XFAIL at:
https://sourceware.org/gdb/wiki/GDBTestcaseCookbook
would help too.
>
> Add aliases gdbfail for kfail, and envfail for xfail, that are more intuitive
> to use.
>
> Tested on x86_64-linux.
>
> Any comments?
I think this isn't a good idea:
- We still end up with XFAIL / KFAIL in result logs anyway. People
still need to know the difference.
- It adds different ways to do the same thing. I.e., more things
to learn, when you still need to know about the old way anyway.
Thanks,
Pedro Alves
prev parent reply other threads:[~2020-06-20 15:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 6:43 Tom de Vries
2020-06-20 15:46 ` Pedro Alves [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6ac2b328-76ce-1c0e-8b1d-bd818a0caeae@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox