From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30253 invoked by alias); 13 Jan 2007 15:29:48 -0000 Received: (qmail 30244 invoked by uid 22791); 13 Jan 2007 15:29:45 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 13 Jan 2007 15:29:39 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H5kp5-000797-EI; Sat, 13 Jan 2007 10:29:35 -0500 Date: Sat, 13 Jan 2007 15:29:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Mark Kettenis , gdb@sourceware.org Subject: Re: Test suite docs Message-ID: <20070113152935.GB27250@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Mark Kettenis , gdb@sourceware.org References: <200701131426.l0DEQ6qe026120@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00235.txt.bz2 On Sat, Jan 13, 2007 at 05:07:42PM +0200, Eli Zaretskii wrote: > > > . Where do I find the canonical results for my platform? > > > > In theory one should not see any FAILS, and one should work on > > eliminating any KFAILS. I agree with Mark and I have been working extensively over the last month just to eliminate FAILs on one single platform - we have not cared for the testsuite well, and it's a fantastically hard thing to do because of all the variables. In practice, I always do exactly what Joel described. I keep the last gdb.sum around and diff them. I just use diff. At work we have some rather more sophisticated scripts to compare .sum files but I'm not familiar with them. > FWIW, I present below the failures and unexpected successes on the > system where I ran the test suite (an x86_64 Ubuntu box). With the > exception of Ada/gnatmake related failures, they all seem to be real > problems. In particular, maint.exp, corefile.exp, sigaltstack.exp, > sigbpt.exp, sigstep.exp, and staticthreads/watchthreads look > disturbing. Does anyone else get them on a GNU/Linux system? I would not be disturbed by any of them. > FAIL: gdb.base/corefile.exp: accessing mmapped data in core file (mapping address not found in core file) A change in behavior of the Linux kernel. David Miller and I talked about it again a week or two ago. I know how to make the test pass again but I'm waiting to see what we do to the kernel behavior first. > FAIL: gdb.base/maint.exp: maint info sections .text No idea. > FAIL: gdb.base/sigaltstack.exp: finish from catch LEAF (the program exited) The frame_unwind_address_in_block work I was discussing with Mark is for this test and the related signal tests... > FAIL: gdb.base/sigbpt.exp: stepi; stepi out of handler ...except that some of them are caused by a bug in glibc, which was just recently fixed; your system's probably has the bug. It's not a serious bug in practice, for anything except the gdb testsuite. > FAIL: gdb.threads/staticthreads.exp: running to main in runto > FAIL: gdb.threads/staticthreads.exp: Continue to main's call of sem_post > FAIL: gdb.threads/staticthreads.exp: handle SIG32 helps I have submitted potential patches for this bug to the glibc maintainers periodically for over a year. I've about given up. > FAIL: gdb.threads/watchthreads.exp: threaded watch loop > FAIL: gdb.threads/watchthreads.exp: first watchpoint on args[1] hit > FAIL: gdb.threads/watchthreads.exp: watchpoint on args[0] hit in thread > FAIL: gdb.threads/watchthreads.exp: watchpoint on args[1] hit in thread > FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30 GDB doesn't support this feature. We added the testcase but not the rest of the patch. As I reduce the list of failures on my first target platform to almost none this is coming back to the top of my list. I asked someone from Red Hat to submit an updated version but got no response; I'll poke them again later. -- Daniel Jacobowitz CodeSourcery