public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>,
	       gdb-patches ml <gdb-patches@sourceware.org>
Subject: Re: [RFA] Fix setting of VSX registers
Date: Wed, 28 Jul 2010 21:57:00 -0000	[thread overview]
Message-ID: <m3k4ofl16l.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20100728214252.GY13267@adacore.com> (Joel Brobecker's message of	"Wed, 28 Jul 2010 14:42:52 -0700")

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Tom> One approach would be to refactor these procs so that your use can work.
Tom> I think this would be nice to have -- I think it would be good to have
Tom> fewer boilerplate tests with "synthetic" names, ones that nobody is
Tom> interested in.

Joel> When we discussed the new gdb-testsuite that AdaCore uses, we talked
Joel> about that quite a bit. And unsurprisingly, there was no obvious answer.
Joel> These tests can be an annoyance if all hell breaks lose and they all
Joel> start to fail. A PASS indeed adds little value to the results.  But
Joel> on the other hand, I have always felt that we should verify that these
Joel> commands have the expected results, and that we should get a FAIL if
Joel> we detect something went wrong. Ideally, we wanted to be able to group
Joel> a sequence of commands as one "setup phase" and generate one FAIL if
Joel> part of the sequence fails. But in the end, we decided that it was just
Joel> simpler to treat everything as a test (this is what I have pretty much
Joel> done in dejagnu as well).

Yeah, it is definitely simpler to keep going with what we already have.
At least for me, test suite hacking is in itself not very interesting,
so I usually just opt for the minimal change that works, and move on to
fun things.

If someone is motivated to work on this, though, one approach would be
to separate out the mechanics of sending a command to gdb and matching
responses from the pass/fail reporting.  Then it would be possible to
write a proc that evals its argument and passes or fails based on the
answer:

single_gdb_test "test name here" {
  gdb_send_no_response "set language c";  # throws exception on "failure"
  gdb_send_and_response "print 23" " = 23"
}

... or what have you.

Another thing I've often wanted is to have the tests forced to have
unique names: by having the test frame work automatically include the
.exp name in the test name, and by automatically handling duplicates
somehow (either an error, or appending a counter).

Tom

  reply	other threads:[~2010-07-28 21:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-21 18:59 Thiago Jung Bauermann
2010-07-22 16:06 ` Tom Tromey
2010-07-26 17:31   ` Thiago Jung Bauermann
2010-07-27 15:20     ` Joel Brobecker
2010-07-27 16:14       ` Thiago Jung Bauermann
2010-07-28 21:34     ` Tom Tromey
2010-07-28 21:43       ` Joel Brobecker
2010-07-28 21:57         ` Tom Tromey [this message]
2010-08-18 21:18   ` Thiago Jung Bauermann
2010-08-19  9:50     ` Joel Brobecker
2010-08-19 17:56       ` Thiago Jung Bauermann

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=m3k4ofl16l.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=bauerman@br.ibm.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /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).