Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb@sources.redhat.com
Subject: A testsuite update, for the curious
Date: Tue, 14 Jan 2003 05:04:00 -0000	[thread overview]
Message-ID: <20030114050519.GA5421@nevyn.them.org> (raw)

As of right now, on my system, using GCC 2.95.3 and -gstabs+, I see:

                === gdb Summary ===

# of expected passes            8546
# of unexpected failures        6
# of unexpected successes       4
# of expected failures          168
# of known failures             5
# of untested testcases         9
# of unsupported tests          1


Two XPASS's from constvars.exp.  I think these should just be removed, but
I'll investigate later.

One XPASS from interrupt.exp.  This has been there forever; it comes and
goes; no one knows.

One FAIL from default.exp, "info float".  Patch posted for comments.

Two FAILs from store.exp.  I know how to fix these, after discussing it with
Andrew a few days ago.  I'll do it soon, probably tomorrow.

An XPASS from virtfunc.exp.  If it's actually working correctly we can and
should remove the xfail; I'll investigate later.

One FAIL from gdb.gdb/complaints.exp.  This has been around for a little
while; I haven't looked at it yet.  Oh, it's a bug I see very frequently. 
Given:
93      static int
94      captured_command_loop (void *data)
95      {
96        if (command_loop_hook == NULL)
97          command_loop ();
and GCC 2.95.3 + optimization, we place the breakpoint after the conditional
branch, and lose.  I'm not entirely sure why this happens but it seems that
it may be a bad interaction with my previous workaround for bad stabs from
this compiler (but it's not that simple, since I first remember seeing it
two years or so before I implemented the workaround).  I'll dig through my
notes for the previous patch and see if I can manage to accomodate both
forms of bugginess.  If not, I'm not going to sweat this one too much, but
I'd like to.

One FAIL from killed.exp, which should be a KFAIL.  I'll probably get this
tomorrow, since I missed it my last pass through.

One FAIL from print-threads.exp.  Patch posted Friday for comments; though I
can't really say that I like it, I don't see a better solution to the
problem.


That's five fails easily (or otherwise, for print-threads.exp) addressed,
three xpasses we can probably remove, and one intermittent XPASS.

There's also intermittent schedlock.exp failures (testsuite problem, still
trying to figure out what to do about it), a testsuite bug that only shows
up with a relative path to configure, a testsuite bug (mine) that only shows
up when $objdir == $srcdir, and an intermittent failure in pthreads.exp
(Kevin B. posted a patch for it months ago).  And something else is wrong in
print-threads.exp; I occasionally see a SIGSEGV in the testsuite log.  But I
can't reproduce it often enough to get a good look at it.

Not too shabby.  If I can figure out what to do about the last stabs bug we
can actually have a configuration down to no failures (and six KFAILs,
which do need to be addressed, but my goal here is strictly regression
usability for the testsuite right now) (and 168 XFAILs, which do need to be
itemized and considered eventually).

Then I'll pick another one and go back to work.  Any configuration but this
particular one needs some work in the C++ arena, and we're getting closer to
ready for that every day.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


             reply	other threads:[~2003-01-14  5:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-14  5:04 Daniel Jacobowitz [this message]
2003-01-14  6:50 ` Daniel Jacobowitz
2003-01-14  7:01   ` Daniel Jacobowitz
2003-01-14  8:19 Michael Elizabeth Chastain
2003-01-14 17:26 ` Daniel Jacobowitz
2003-01-14 17:36 Michael Elizabeth Chastain

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=20030114050519.GA5421@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb@sources.redhat.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