public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Simon Marchi <simon.marchi@ericsson.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/testsuite: Don't attempt tests if they fail to compile
Date: Fri, 12 Jan 2018 10:23:00 -0000	[thread overview]
Message-ID: <20180112102308.GN3026@embecosm.com> (raw)
In-Reply-To: <bf7d7dc6-1453-38be-09cc-367b64a64372@ericsson.com>

* Simon Marchi <simon.marchi@ericsson.com> [2018-01-11 17:03:51 -0500]:

> On 2018-01-11 02:00 PM, Andrew Burgess wrote:
> > In the gdb.base/whatis-ptype-typedefs.exp test, if the test program
> > fails to compile, don't run the tests.
> 
> Hi Andrew,
> 
> That would make the test similar to other test, in that if we fail to
> build the test program it's not a failure (it shows as UNTESTED, doesn't
> make the test run fail).  I find it's a strange behavior though.  If a
> test program starts not building for some reason, I'd certainly like to
> know (e.g. it could be UNRESOLVED), instead of it silently failing.
> 
> Any other opinion?

If the test fails to compile we don't get a silent failure, as you
mention, we get the UNTESTED.  Changing this to something stronger,
like UNRESOLVED, would I fear make cases where we legitimately can't
compile a test program seem worse than they really are.

The concern about missing the case where a test program goes from
compiling to not compiling is fair, however, I don't think that it's
something we need to worry about.  My understanding of the "normal"
testing flow for GDB is to compare against a baseline set of results,
a few hundred tests disappearing should raise a red flag, and once the
developer has realised that this particular test script has something
weird going on, the extra UNTESTED should guide them to the cause of
the problem.

The failed to prepare leading to skipping the tests seems like the
"standard" pattern within the GDB testsuite, so, if you agree, I think
having this test fall in line with that is probably a good thing.
That doesn't mean we can't change the standard pattern in the future
if we can come up with a better model (though I don't have any good
suggestions).

Thanks,
Andrew

  reply	other threads:[~2018-01-12 10:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-11 19:01 Andrew Burgess
2018-01-11 22:04 ` Simon Marchi
2018-01-12 10:23   ` Andrew Burgess [this message]
2018-01-12 11:46     ` Joel Brobecker
2018-01-12 12:36     ` Simon Marchi

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=20180112102308.GN3026@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@ericsson.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).