This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Fix xfail Sparc pattern
- From: "David S. Miller" <davem at redhat dot com>
- To: ac131313 at cygnus dot com
- Cc: mec at shout dot net, fnasser at redhat dot com, cagney at cygnus dot com, gdb-patches at sources dot redhat dot com
- Date: Thu, 18 Apr 2002 14:55:31 -0700 (PDT)
- Subject: Re: [PATCH] Fix xfail Sparc pattern
- References: <200204181606.g3IG6U914843@duracef.shout.net><3CBEF272.3060500@cygnus.com>
From: Andrew Cagney <ac131313@cygnus.com>
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.