Re: [PATCH] Fix xfail Sparc pattern

Re: [PATCH] Fix xfail Sparc pattern

[Michael Elizabeth Chastain]

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.

Michael C

Re: [PATCH] Fix xfail Sparc pattern

[Andrew Cagney]

> 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.

Andrew

Re: [PATCH] Fix xfail Sparc pattern

[David S. Miller]

   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.

Re: [PATCH] Fix xfail Sparc pattern

[Andrew Cagney]

David, note the e-mail below:

> AFAIK, generic dummy frames work only with the AT_ENTRY mechanism.
> 
> But for 32 bit SPARC ABI we need ON_STACK, see
> http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00064.html
> http://sources.redhat.com/ml/gdb-patches/2000-05/msg00041.html
> for an explanation.
> 
> I am afraid that we have to extend the generic dummy frame code to allow
> ON_STACK, if we want to use generic dummy frames for SPARC.
> 
> 
>> Hello,
>> 
>> If I remember one of those unwritten ``grand plans'' correctly, the 
>> intent is to have all targets switched to ``generic dummy frames''.  True?
>> 
>> Among other things, generic dummy frames do not save/restore registers 
>> on the target stack (instead they are cached locally) and this should 
>> improve the overall performance of an inferior function call.
>> 
>> Anyway, the thing that prompts this is PC_IN_CALL_DUMMY(PC, SP, FP). 
>> There are several implementations.  Only two:
>> 
>> - generic: looks for the FP in the list of dummy frames
>> - stack: looks for PC in [FP..SP)
>> 
>> require the SP/FP parameters.  I've a patch to fix the first one (search 
>> for the PC).  If the ARM, SPARC and i386 can switch to generic dummy 
>> frames then those parameters can be eliminated and all calls simplified.
>> 
>> Any chance of having these converted?
>> 
>> Andrew
>> 
>> 
>> 
> 
> 
> 

Re: [PATCH] Fix xfail Sparc pattern

[David S. Miller]

   From: Andrew Cagney <ac131313@cygnus.com>
   Date: Thu, 18 Apr 2002 18:29:29 -0400

   David, note the e-mail below:
   
   > AFAIK, generic dummy frames work only with the AT_ENTRY mechanism.
   > 
   > But for 32 bit SPARC ABI we need ON_STACK, see
   > http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00064.html
   > http://sources.redhat.com/ml/gdb-patches/2000-05/msg00041.html
   > for an explanation.
   > 
   > I am afraid that we have to extend the generic dummy frame code to allow
   > ON_STACK, if we want to use generic dummy frames for SPARC.

True, there is a comment in my upcoming patches which looks like this:

+      /* This is no way we could ever use AT_ENTRY_POINT for call dummy
+        on 32-bit Sparc targets.  The reason is for proper nested handling
+        of the unimp-after-call convention used when returning structures
+        from functions.  */

What I am referring to more specifically is the dummy frame
descriptors which the generic dummy frame support creates and
keeps track of.  That is generic, and independant of the
CALL_DUMMY mechanism a target uses.

That aspect is perfect, and I implemented something similar in my
sparc patches.  That bit of the generic dummy frame bits could be
reused instead of duplicating such state tracking in sparc specific
code.

Isn't it possible to use ON_STACK for dummy frames and still use
the dummy frame tracking support provided by generic dummy frames?
I don't see anything specific to the CALL_DUMMY mechanism used in
those structures.

Re: [PATCH] Fix xfail Sparc pattern

[Andrew Cagney]

> What I am referring to more specifically is the dummy frame
> descriptors which the generic dummy frame support creates and
> keeps track of.  That is generic, and independant of the
> CALL_DUMMY mechanism a target uses.
> 
> That aspect is perfect, and I implemented something similar in my
> sparc patches.  That bit of the generic dummy frame bits could be
> reused instead of duplicating such state tracking in sparc specific
> code.
> 
> Isn't it possible to use ON_STACK for dummy frames and still use
> the dummy frame tracking support provided by generic dummy frames?
> I don't see anything specific to the CALL_DUMMY mechanism used in
> those structures.

Yes, that is the theory.  See the very recent patch:

[RFA] Save the call dummy address
http://sources.redhat.com/ml/gdb-patches/2002-04/msg00501.html

Andrew

[PATCH] Fix xfail Sparc pattern

[David S. Miller]

The xfail here applies to all Sparc platforms, not just sparc-*.

2002-04-17  David S. Miller  <davem@redhat.com>

	* 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*-*-*"

Re: [PATCH] Fix xfail Sparc pattern

[Fernando Nasser]

"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  <davem@redhat.com>
> 
>         * 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