From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28126 invoked by alias); 25 Nov 2005 02:50:45 -0000 Received: (qmail 28113 invoked by uid 22791); 25 Nov 2005 02:50:44 -0000 X-Spam-Check-By: sourceware.org Received: from ausmtp04.au.ibm.com (HELO ausmtp04) (202.81.18.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Nov 2005 02:50:42 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp04 (8.12.10/8.12.10) with ESMTP id jAP2oO9A244978; Fri, 25 Nov 2005 13:50:24 +1100 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.250.242]) by sd0208e0.au.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAP2rSSx205116; Fri, 25 Nov 2005 13:53:29 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11/8.13.3) with ESMTP id jAP2oQap025720; Fri, 25 Nov 2005 13:50:26 +1100 Received: from [9.181.133.252] ([9.181.133.252]) by d23av01.au.ibm.com (8.12.11/8.12.11) with ESMTP id jAP2oLuM025533; Fri, 25 Nov 2005 13:50:23 +1100 Date: Fri, 25 Nov 2005 02:51:00 -0000 From: Wu Zhou To: Mark Kettenis cc: brobecker@adacore.com, gdb@sources.redhat.com, gdb-testers@sources.redhat.com Subject: Re: First release candidate for GDB 6.4 available In-Reply-To: <200511242233.jAOMXQmq024151@elgar.sibelius.xs4all.nl> Message-ID: References: <20051122083855.GH1635@adacore.com> <200511242233.jAOMXQmq024151@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00549.txt.bz2 Hi Mark, On Thu, 24 Nov 2005, Mark Kettenis wrote: > > Date: Wed, 23 Nov 2005 11:54:40 +0800 (CST) > > From: Wu Zhou > > > > I run this RC on ppc64 platform as both 32-bits and 64-bits application. > > Here is the summary. I also list the x86 summary as reference. > > > > ppc64, 64-bits gdb, 32-bits testcase: > > ====================================== > ... > > FAIL: gdb.base/recurse.exp: continue to recurse (a = 8) > > FAIL: gdb.base/recurse.exp: continue to recurse (a = 7) > > FAIL: gdb.base/recurse.exp: continue to recurse (a = 6) > > FAIL: gdb.base/recurse.exp: continue to recurse (a = 5) > > FAIL: gdb.base/recurse.exp: continue to second instance watchpoint, first time > > FAIL: gdb.base/recurse.exp: continue to recurse (a = 4) > > FAIL: gdb.base/recurse.exp: continue to recurse (a = 3) > > FAIL: gdb.base/recurse.exp: continue to recurse (a = 2) > > FAIL: gdb.base/recurse.exp: continue to recurse (a = 1) > > FAIL: gdb.base/recurse.exp: continue to second instance watchpoint, second time The mainline GDB-6.3 only report three failures here. And RHEL4's GDB, which is based on 6.3.0 and added some of their own patch, report all ok. So I believe that these are regression. BTW. I am also tracking these problems and guessing that it might be related to the software watchpoint code. I did find the code to single step the inferior, but I didn't find the code to check whether these watched variables get changed or not. (These code seems somewaht messy to me, :-) Would you please give some pointer? Thanks in advance! > ... > > FAIL: gdb.cp/anon-union.exp: print w 1 > > FAIL: gdb.cp/anon-union.exp: print z 1 > > FAIL: gdb.cp/anon-union.exp: print w 2 > > FAIL: gdb.cp/anon-union.exp: print z 2 > > FAIL: gdb.cp/anon-union.exp: print w 3 > > FAIL: gdb.cp/anon-union.exp: print z 3 I guess that GDB don't know how to handle anonymous union yet. I ever saw these failures in a few platform. And also see them ok on others. The difference I find is that some version of gcc handle the anonymous union members as normal variables, others don't. > > FAIL: gdb.gdb/observer.exp: second observer attached; check second observer counter value > > FAIL: gdb.gdb/observer.exp: 1st observer added; check first observer counter value > > FAIL: gdb.gdb/observer.exp: 2nd observer added; check first observer counter value > > FAIL: gdb.gdb/observer.exp: 2nd observer added; check second observer counter value > > FAIL: gdb.gdb/observer.exp: 3rd observer added; check first observer counter value > > FAIL: gdb.gdb/observer.exp: 3rd observer added; check second observer counter value > > FAIL: gdb.gdb/observer.exp: 3rd observer added; check third observer counter value > > FAIL: gdb.gdb/observer.exp: 2nd observer removed; check first observer counter value > > FAIL: gdb.gdb/observer.exp: 2nd observer removed; check third observer counter value > > FAIL: gdb.gdb/observer.exp: 1st observer removed; check third observer counter value > > FAIL: gdb.gdb/observer.exp: three observers added; check first observer counter value > > FAIL: gdb.gdb/observer.exp: three observers added; check second observer counter value > > FAIL: gdb.gdb/observer.exp: three observers added; check third observer counter value > > FAIL: gdb.gdb/observer.exp: third observer removed; check first observer counter value > > FAIL: gdb.gdb/observer.exp: third observer removed; check second observer counter value > > FAIL: gdb.gdb/observer.exp: second observer removed; check first observer counter value > ... I remember saw these error with an earlier gdb version this year. But don't take any looks into them. GDB-6.3 testsuite report "Couldn't test self" and then exit on my POWER4 box. Don't know why. Will take some look into them later. > For OpenBSD, the failures above are regressions from 6.3, and I think > it's safe to assume they're regressions for Linux too. They were > still OK in 6.3.50.20050911-cvs, and I think remembering I've already > seen them fail in early november. Don't know if this is serious > enough to delay the release. I'll try to track this down, and > hopefully will find the problem. If it's too late for 6.4 we should > release 6.4.1 with the fix. That is quite reasonable to me. BTW. If you have any patch, please let me know. I am very happy to try them. Regards - Wu Zhou