From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23642 invoked by alias); 18 Apr 2002 22:04:05 -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 23578 invoked from network); 18 Apr 2002 22:04:03 -0000 Received: from unknown (HELO pizda.ninka.net) (216.101.162.242) by sources.redhat.com with SMTP; 18 Apr 2002 22:04:03 -0000 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id OAA24635; Thu, 18 Apr 2002 14:55:31 -0700 Date: Thu, 18 Apr 2002 15:04:00 -0000 Message-Id: <20020418.145531.68100471.davem@redhat.com> To: ac131313@cygnus.com Cc: mec@shout.net, fnasser@redhat.com, cagney@cygnus.com, gdb-patches@sources.redhat.com Subject: Re: [PATCH] Fix xfail Sparc pattern From: "David S. Miller" In-Reply-To: <3CBEF272.3060500@cygnus.com> References: <200204181606.g3IG6U914843@duracef.shout.net> <3CBEF272.3060500@cygnus.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00610.txt.bz2 From: Andrew Cagney Date: Thu, 18 Apr 2002 12:21:06 -0400 > Fernando Nasser writes: > >> I wonder if we should activate this test and see where it fails and >> start marking as XFAILS (KFAILS actually) and entering a bug report >> when we see the regressions. > > I think so. The comment indicates that this is due to a problem > inside gdb, not a problem with the environment, so that XFAIL is wrong > in the first place. > > This is the old "XFAIL means an external program is not functional" > versus "XFAIL means that gdb is wrong but it's too painful to fix" > argument. Sounds right to me. The ``correct fix'' is convert the code to generic dummy frames (which in turn means work on generic dummy frames) but both of those are GDB bugs. I agree too, mark it as expected to pass and use generic dummy frame support to fixup targets that show up to fail the test. In fact, even though I had been over this code a million times, I failed to notice the generic dummy frame mechanism, and I in fact reimplemented this in some of my pending Sparc64 fixes. Thanks Andrew for pointing this out! I'll fixup Sparc to use this before I submit that Sparc64 fixes I have pending.