From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-14393-listarch-gdb-patches=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 1463 invoked by alias); 18 Apr 2002 22:37:06 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 1454 invoked from network); 18 Apr 2002 22:37:06 -0000
Received: from unknown (HELO pizda.ninka.net) (216.101.162.242)
  by sources.redhat.com with SMTP; 18 Apr 2002 22:37:06 -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 PAA24941;
	Thu, 18 Apr 2002 15:28:35 -0700
Date: Thu, 18 Apr 2002 15:37:00 -0000
Message-Id: <20020418.152834.121227947.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" <davem@redhat.com>
In-Reply-To: <3CBF48C9.30201@cygnus.com>
References: <3CBEF272.3060500@cygnus.com>
	<20020418.145531.68100471.davem@redhat.com>
	<3CBF48C9.30201@cygnus.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-04/txt/msg00614.txt.bz2

   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.