From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16586 invoked by alias); 23 Sep 2004 17:08:32 -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 16577 invoked from network); 23 Sep 2004 17:08:31 -0000 Received: from unknown (HELO hall.mail.mindspring.net) (207.69.200.60) by sourceware.org with SMTP; 23 Sep 2004 17:08:31 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1CAX54-0002sc-00; Thu, 23 Sep 2004 13:08:30 -0400 Received: from mindspring.com (unknown [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id 5BF4E4B35A; Thu, 23 Sep 2004 12:45:15 -0400 (EDT) Date: Thu, 23 Sep 2004 17:08:00 -0000 From: Michael Chastain To: pgilliam@us.ibm.com, gdb-patches@sources.redhat.com Subject: Re: [PATCH] Fixes testsuit/gdb.base/annota1.exp Cc: cagney@gnu.org Message-ID: <4152FD9A.nail1OT1PXJKP@mindspring.com> References: <200409211441.33901.pgilliam@us.ibm.com> <200409220953.53052.pgilliam@us.ibm.com> <4151D7B4.1080306@gnu.org> <200409221910.41605.pgilliam@us.ibm.com> In-Reply-To: <200409221910.41605.pgilliam@us.ibm.com> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00371.txt.bz2 I'm Trying to catch up on the thread. I'll do all the fun pontificating here and then get to the specific revised backtrace-past-main patch in another message. Let's start with the delayed breakpoint message. The actual output of gdb is: warning: Breakpoint 3 address previously adjusted from 0x80c5a66c78 to 0x80c59643a8. ^Z^Zbreakpoint 3 That's an observed fact from gdb.log_after_bp_adjust_patch There are two separate questions that arise from this fact: (1) should gdb print this warning? (2) if gdb prints this warning, is that a bug in gdb? Part of the answer to (2) is that the test script should have a separate arm in gdb_test_multiple for that warning. So you are on the right track there. The next question is what the new arm should do. It can either PASS or KFAIL. That depends on the answer to (1). If it's okay for gdb to print this warning, then the result should be PASS. If it's not okay for gdb to print this warning, then the result should be KFAIL. Sometimes you really have to hold people's feet to the fire to get an answer to (2). People will say "it would be better if gdb did not print XXX, but we kinda have to for now", and you have to keep asking "gdb prints XXX. Is that a bug or not?" If you can't get an answer, it's always safe to file a PR and KFAIL it. If it is a KFAIL, or even if it's a PASS, it's useful to put in a comment that recapitulates the discussion about the feature. Something like: "this happens on ppc-64, because blah blah, gilliam 2004-09-23". paul> It it well known that a 'KFAIL' durring a test may have nothing paul> to do with what is being tested? Yes. The very first KFAIL was in gdb.cp/annota2.exp, for PR gdb/544, which is not an annotation bug but is actually a control-c handling race in the event loop. Michael