Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: David Carlton <carlton@math.stanford.edu>
To: Michael Elizabeth Chastain <mec@shout.net>
Cc: fnasser@redhat.com, ac131313@redhat.com, drow@mvista.com,
	gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] Remove all setup_xfail's from testsuite/gdb.mi/
Date: Fri, 17 Jan 2003 19:16:00 -0000	[thread overview]
Message-ID: <ro1y95j37tr.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <200301171900.h0HJ03A04642@duracef.shout.net>

On Fri, 17 Jan 2003 13:00:03 -0600, Michael Elizabeth Chastain <mec@shout.net> said:

> Good morning xfail crew,
> There are a lot of xfail's in the corpus, but the number is shrinking
> steadily with time.

>   % cd testsuite
>   % grep -r setup_xfail gdb.* | wc

>     5.2.1               649
>     5.3                 577
>     HEAD%20030115       517

> After sleeping on the problem, I like Daniel J's path for a while.
> Just keep banging on the test suite and reducing that "517" number with
> no more machinery and no Andrew C Big Rip.

Personally, I basically prefer that approach, too.  I'm gradually
going through the current non-{PASS,KFAIL} results that I see on my
test runs in gdb.c++, and investigating them; I'm not distinguishing
between XFAIL and FAIL (and XPASS, for that matter) when doing so.
Once I'm done with that, I'll move on to the xfail's that I don't see;
I've noticed that there are an awful lot of DWARF 1 ones, which I
assume actually are legit.  (And I also want to bring in bugs from the
database into the testsuite, and add some new bugs that I've seen in
my own C++ debugging, but that's a separate issue.)

On the other hand, while by now it's clear that Andrew would meet
considerable resistance in a wholescale ripping out of XFAIL's in
gdb.c++, what Andrew was actually proposing (if memory serves me well)
is starting by ripping them out of gdb.mi.  Andrew's one of the
maintainers there; if he thinks that ripping them out would make the
results of test runs in gdb.mi more accurate, then doing so sounds
entirely reasonable to me.  Elena's the other maintainer of the mi
tests; I plan to keep her quite busy enough reviewing my various
forthcoming symtab patches that she won't want have time to audit the
mi tests, either.

I'm not sure that I see the urgency of ripping them out of the
testsuite as a whole, given that there is actual concrete progress
being made in cleaning up the testsuite right now.

David Carlton
carlton@math.stanford.edu


  reply	other threads:[~2003-01-17 19:16 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-17 19:00 Michael Elizabeth Chastain
2003-01-17 19:16 ` David Carlton [this message]
2003-01-17 19:20   ` David Carlton
2003-01-17 19:30     ` Daniel Jacobowitz
2003-01-17 19:28 ` Andrew Cagney
  -- strict thread matches above, loose matches on Subject: below --
2003-01-17 19:32 Michael Elizabeth Chastain
2003-01-17 19:28 Michael Elizabeth Chastain
2003-01-17 19:34 ` Daniel Jacobowitz
2003-01-16 20:06 Michael Elizabeth Chastain
2003-01-16 20:12 ` Daniel Jacobowitz
2003-01-17 14:12   ` Fernando Nasser
2003-01-17 16:05     ` Andrew Cagney
2003-01-17 14:26 ` Fernando Nasser
2003-01-16 17:12 Michael Elizabeth Chastain
2003-01-16 17:07 Michael Elizabeth Chastain
2003-01-15 17:44 Michael Elizabeth Chastain
2003-01-15 17:51 ` Daniel Jacobowitz
2003-01-16 14:27   ` Fernando Nasser
2003-01-16 14:30     ` Daniel Jacobowitz
2003-01-16 14:46       ` Fernando Nasser
2003-01-16 14:52         ` Daniel Jacobowitz
2003-01-16 15:46     ` Andrew Cagney
2003-01-16 14:20 ` Fernando Nasser
2002-10-24 11:41 Andrew Cagney
2002-10-24 12:09 ` Daniel Jacobowitz
2002-10-24 12:29   ` Andrew Cagney
2002-10-24 12:58     ` Daniel Jacobowitz
2002-10-24 14:22       ` Andrew Cagney
2002-10-24 14:26         ` Daniel Jacobowitz
2002-10-24 14:39           ` Michael Snyder
2002-10-24 16:31             ` Andrew Cagney
2002-10-24 16:36               ` Michael Snyder
2002-10-24 14:50           ` Andrew Cagney
2002-10-24 14:58             ` Michael Snyder
2002-10-24 15:31               ` Ben Elliston
2002-10-24 16:44               ` Andrew Cagney
2002-10-24 17:35                 ` Michael Snyder
2002-10-24 18:25                   ` Andrew Cagney
2002-10-24 14:18 ` Michael Snyder
2002-10-24 14:32   ` Andrew Cagney
2002-10-24 14:39 ` David Carlton
2002-10-24 14:57   ` Andrew Cagney
2002-10-24 15:00     ` Michael Snyder
2002-10-24 15:26     ` David Carlton
2002-10-24 15:36       ` Andrew Cagney
2003-01-15 15:55 ` Andrew Cagney
2003-01-15 17:25   ` Fernando Nasser
2003-01-16 16:53     ` Andrew Cagney
2003-01-16 17:05       ` Daniel Jacobowitz
2003-01-16 19:03         ` Andrew Cagney
2003-01-16 19:55           ` 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=ro1y95j37tr.fsf@jackfruit.Stanford.EDU \
    --to=carlton@math.stanford.edu \
    --cc=ac131313@redhat.com \
    --cc=drow@mvista.com \
    --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