Re: [PATCH] Fix xfail Sparc pattern

["David S. Miller" <davem@redhat.com>]

   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.