Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Rob Savoye <rob@welcomehome.org>
To: Michael Elizabeth Chastain <mec@shout.net>
Cc: ac131313@cygnus.com, drow@mvista.com, eliz@is.elta.co.il,
	fnasser@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: RFC: KFAIL DejaGnu patch
Date: Tue, 09 Apr 2002 09:34:00 -0000	[thread overview]
Message-ID: <20020409104312.M11086@welcomehome.org> (raw)
In-Reply-To: <200204091613.g39GDI409116@duracef.shout.net>; from Michael Elizabeth Chastain on Tue, Apr 09, 2002 at 11:13:18AM -0500

On Tue, Apr 09, 2002 at 11:13:18AM -0500, Michael Elizabeth Chastain wrote:

> I'm not looking for any changes in 1.4.3.  Think of this more as one
> user's feedback.  If you get any good ideas from it, that's fine.
 
  I'm always looking for constructive comments from end users.

> Now that I know Dejagnu is actively maintained, maybe I'll pick this
> one up myself.  I would have to learn more TCL but Dejagnu is not
> that large.

  DejaGnu has been mostly actively maintained except for a period 5-6 years
ago where I needed a break... plus occasionally income generating projects
get in the way... Gotta pay the bills...

> the documentation is that the human is deciding whether the test passed
> or not.  Actually a human is needed here to fix the tool, or perhaps fix
> the testing environment.  I think TIMEOUT would be more accurate than
> using UNRESOLVED for this.
 
  According to POSIX though, UNRESOLVED is the test state, if GDB crashed
while executing a test case. If GDB crashed between test cases, then TIMEOUT,
would be appropriate. Maybe between tests, GDB should be checked to see if
it's crashed...

> Right now we use FAIL "... (timeout)" for this, so in principle, we're
> getting the information we need.  So I can live without this if we really

  In a sense FAIL is appropriate, since a test case fails if GDB crashes. :-)
the FAIL should automatically become an UNRESOLVED, unless somewhere in the
GDB tests the threshold is changed to turn off this feature. Mind you, there
is no real need to have the GDB test suite be POSIX conforming in behavior, so
whatever you do that works is fine.

> Another way to look at it: as projects get larger, the roles separate.
> I'm planning to publish my scripts so that lots of people can run gdb
> tests and mail in useful information.  My end goal is an Internet scale

  Maybe I should include your scripts in dejagnu/contrib. I used to have the
ancient ones we used at Cygnus there till they've kindof fallen out of use...

  Just as a note, DejaGnu now has some support for unit testing. You basically
include a dejagnu.h file, and your test case (typically on an embedded system)
spits out standard test states, and DejaGnu then parses those to produce the
final results. This is probably more useful for GCC or libstdc++ testing, but
I've been using this feature alot lately for customers. (which is why I wrote it)
I rarely write any new code these days without an associated test case.

	- rob -


  reply	other threads:[~2002-04-09 16:34 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-09  9:13 Michael Elizabeth Chastain
2002-04-09  9:34 ` Rob Savoye [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-04-08 11:56 Michael Elizabeth Chastain
2002-04-08 10:34 Michael Elizabeth Chastain
2002-04-08 11:38 ` Daniel Jacobowitz
2002-04-09  7:50 ` Rob Savoye
2002-04-08  9:57 Michael Elizabeth Chastain
2002-04-07 18:41 Michael Elizabeth Chastain
2002-04-07  9:10 Michael Elizabeth Chastain
2002-04-06 14:40 Michael Elizabeth Chastain
2002-04-05 17:57 Michael Elizabeth Chastain
2002-04-05 16:51 Michael Elizabeth Chastain
2002-04-05  9:53 RFC: KFAILs [Was: [RFA/mi-testsuite] XFAIL mi*-console.exp] Michael Elizabeth Chastain
2002-04-05 16:32 ` RFC: KFAIL DejaGnu patch Fernando Nasser
2002-04-05 17:05   ` Andrew Cagney
2002-04-07 16:25     ` Rob Savoye
2002-04-05 17:10   ` Daniel Jacobowitz
2002-04-05 17:40     ` Andrew Cagney
2002-04-08  8:37     ` Fernando Nasser
2002-04-07 16:29   ` Rob Savoye
2002-04-07 22:05     ` Eli Zaretskii
2002-04-08  8:22       ` Rob Savoye
2002-04-08  8:52         ` Fernando Nasser
2002-04-08  9:01           ` Rob Savoye
2002-04-08  8:41     ` Fernando Nasser
2002-04-08  9:00       ` Rob Savoye
2002-04-08 13:55         ` Andrew Cagney
2002-04-08 16:21           ` Rob Savoye
2002-04-08 16:34             ` Andrew Cagney
2002-04-08 16:48               ` Rob Savoye
2002-04-08 16:58                 ` Andrew Cagney
2002-04-08 17:09                   ` Rob Savoye
2002-04-08 23:58                     ` Eli Zaretskii
2002-04-09  7:38                       ` Rob Savoye
2002-04-08 23:53               ` Eli Zaretskii
2002-04-09  7:06                 ` Daniel Jacobowitz

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=20020409104312.M11086@welcomehome.org \
    --to=rob@welcomehome.org \
    --cc=ac131313@cygnus.com \
    --cc=drow@mvista.com \
    --cc=eliz@is.elta.co.il \
    --cc=fnasser@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=mec@shout.net \
    /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