From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5089 invoked by alias); 18 Apr 2002 14:48:19 -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 5060 invoked from network); 18 Apr 2002 14:48:10 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 18 Apr 2002 14:48:10 -0000 Received: from redhat.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA07598; Thu, 18 Apr 2002 07:48:07 -0700 (PDT) Message-ID: <3CBEDBEC.30BE86F8@redhat.com> Date: Thu, 18 Apr 2002 07:48:00 -0000 From: Fernando Nasser Organization: Red Hat Canada X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: gdb-patches@sources.redhat.com, Andrew Cagney , Michael Elizabeth Chastain Subject: Re: [PATCH] Fix xfail Sparc pattern References: <200204171955.MAA09313@nuts.ninka.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00588.txt.bz2 "David S. Miller" wrote: > > The xfail here applies to all Sparc platforms, not just sparc-*. ^^^^^^^ > David, You mean _does not_ apply. The code is actually clearing the xfail setting for all architectures. But before doing this, lets ask some questions areound (see below). The way this is set up it will normally XFAIL unless one explicitly unmark it. A maintenance nightmare. The comments say that the problem is: # The problem is that GDB confuses stepping through the call # dummy with hitting the breakpoint at the end of the call dummy. # Will be fixed once all architectures define # CALL_DUMMY_BREAKPOINT_OFFSET. Some architectures (listed in the clear_xfail commands) already define it. I suspect that many others may do it as well and noone ever unmarked the xfail for this test. Also, HP seems to define CALL_DUMMY_HAS_COMPLETED that also makes this test pass. I wonder if this is some HP equivalent to the above. The comments also say that this will work, regardless of the macro, for the targets that: # This doesn't occur if the call dummy starts with a call, # because we are out of the dummy by the first time the inferior # stops. and also for: # It works with the generic inferior function calling code too. So, here is a question for Andrew: what is the current status on CALL_DUMMY_BREAKPOINT_OFFSET (and CALL_DUMMY_HAS_COMPLETED)? 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. Regards to all. Fernando > 2002-04-17 David S. Miller > > * gdb.base/watchpoint.exp: Fix sparc xfail to be sparc*-*-* > > --- ./testsuite/gdb.base/watchpoint.exp.~1~ Tue Apr 16 10:56:47 2002 > +++ ./testsuite/gdb.base/watchpoint.exp Tue Apr 16 10:58:53 2002 > @@ -390,7 +390,7 @@ proc test_stepping {} { > # The following architectures define CALL_DUMMY_BREAKPOINT_OFFSET. > clear_xfail "alpha-*-*" > clear_xfail "mips*-*-*" > - clear_xfail "sparc-*-*" > + clear_xfail "sparc*-*-*" > clear_xfail "hppa*-*-*bsd*" > # It works with the generic inferior function calling code too. > clear_xfail "mn10200*-*-*" -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9