From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6532 invoked by alias); 14 Jan 2003 05:04:59 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 6522 invoked from network); 14 Jan 2003 05:04:57 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 14 Jan 2003 05:04:57 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18YL8Z-0007mE-00 for ; Tue, 14 Jan 2003 01:05:27 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18YJGJ-00027B-00 for ; Tue, 14 Jan 2003 00:05:19 -0500 Date: Tue, 14 Jan 2003 05:04:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: A testsuite update, for the curious Message-ID: <20030114050519.GA5421@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00223.txt.bz2 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