From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21186 invoked by alias); 22 Sep 2004 19:54:04 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21177 invoked from network); 22 Sep 2004 19:54:02 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 22 Sep 2004 19:54:02 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8MJs2CW031823 for ; Wed, 22 Sep 2004 15:54:02 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8MJrWr19531; Wed, 22 Sep 2004 15:53:37 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 055AB28D2; Wed, 22 Sep 2004 15:51:16 -0400 (EDT) Message-ID: <4151D7B4.1080306@gnu.org> Date: Wed, 22 Sep 2004 19:54:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: pgilliam@us.ibm.com, Michael Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Fixes testsuit/gdb.base/annota1.exp References: <200409211441.33901.pgilliam@us.ibm.com> <4151851B.1040100@gnu.org> <200409220953.53052.pgilliam@us.ibm.com> In-Reply-To: <200409220953.53052.pgilliam@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00356.txt.bz2 Paul, Some history For GDB, if we analize a test failure and identify a bug, we can mark it up with a KFAIL (and file a bug report). This way we leave a trail of what is analysed while not hiding the bugs. In the past people were going round XFAILing or PASSing such cases (the sole objective being to artifically deflate the fail numbers). Another past mistake was to hack test cases so that they would (incorrectly) accept bogus backtraces. Again, if we encounter this, we should KFAIL it, or better fix the bug. > Thanks for your comments. See below... > > On Wednesday 22 September 2004 06:58, Andrew Cagney wrote: > >>>> > On powerpc64--linux, annota1.exp has two problems: >>>> > >>>> > 1) A breakpoint in a shared object may be 'delayed'. This changes GDB's >>>> > responce: both when the breakpoint is set and when it is hit. >> >>> >>> I'm not sure what you mean. On i386 GNU/Linux, annota1.exp gets zero >>> fails so this would suggest some sort of ISA specific bug? > > > The problem is specific to any ISA that uses delayed breakpoints... I think > that's just the Power64. Keep going .... what problem? >>> I see this lets GDB accept the ``warning: adjusting breakpoint'' >>> message. I'm wondering if GDB should even emit the warning - it and the >>> descriptor are very much integral parts of the ABI - and hence should be >>> trying to always display the descriptor symbol and code address (and not >>> display the dot symbol). > > > I think I agree. Unless this level of detail is needed by the user for some > reason. And I don't think they need to be reminded every time the breakpoint > is hit. But that's the way the code is. The testsuite should reflect the > way the code is, and to a certain extent, the way it was. > > >>> >>> What's going to happen when 64-bit PPC stops emiting those dot symbols? > > > When this happens, then the regexp that I added would never be matched. So > Its kind of self correcting. This sounds like a KFAIL. > Some time later we can just remove the regexp. (that never happens) >>> >> >>>> > 2) Due to a bug (I which I knew the number), GDB 'skids' past the >>>> > top-of-stack when doing a backtrace. This causes two extra and severial >>>> > garbage stack frames to be displayed, eventually getting an error. >> >>> >>> You mean backtracing past main - that code was recently rewritten. >>> However, there's apparently no test case for the feature, perhaphs it it >>> should first be added and fixed?. Anyway, I don't think we should be >>> passing a broken backtrace. >>> > > > Well... this doesn't 'pass' a broken backtrace, it just doesn't let a broken > backtrace stop it from testing what it is really interested in: annotations. That sounds like a KFAIL. > I agree that we need a test for the 'backtracing past main' problem. I will > post one later today, along with a log showing it in action. Which .exp file > would you suggest I use as a model? The first half of siginfo.*? Andrew