From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-14720-listarch-gdb-patches=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 31263 invoked by alias); 24 Apr 2002 15:33:22 -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 31240 invoked from network); 24 Apr 2002 15:33:19 -0000
Received: from unknown (HELO pizda.ninka.net) (216.101.162.242)
  by sources.redhat.com with SMTP; 24 Apr 2002 15:33:19 -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 IAA30858;
	Wed, 24 Apr 2002 08:23:53 -0700
Date: Wed, 24 Apr 2002 08:33:00 -0000
Message-Id: <20020424.082353.15613374.davem@redhat.com>
To: kevinb@redhat.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Locate sparc64 arguments correctly
From: "David S. Miller" <davem@redhat.com>
In-Reply-To: <1020423230940.ZM10851@localhost.localdomain>
References: <20020420.020906.44150275.davem@redhat.com>
	<davem@redhat.com>
	<1020423230940.ZM10851@localhost.localdomain>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-04/txt/msg00941.txt.bz2

   From: Kevin Buettner <kevinb@redhat.com>
   Date: Tue, 23 Apr 2002 16:09:40 -0700

   I agree that this is the problem, but, when you do this...
   
   > +/* Debugging information stores LOC_ARG/LOC_REF_ARG offsets with the
   > +   sparc64 stack bias present, this undoes that so that users of
   > +   FRAME_ARGS_ADDRESS use the right location.  */
   > +
   > +static CORE_ADDR
   > +sparc64_frame_args_address (struct frame_info *fi)
   > +{
   > +  return fi->frame - 2047;
   > +}
   
   ...does the output from ``info frame'' still look reasonable?
   
You're right, it does the wrong thing for info frame.

This indicates that FRAME_ARGS_ADDRESS is being used for two entirely
different purposes.  One is to interpret debugging information, the
other is to print arguments on the stack via info frame.

This particular case would be cured by adjusting what we use for
FRAME_ARGS_SKIP on a 64-bit sparc target such that the STACK bias is
calcelled back out.  I will make that modification to my patch and
resubmit.

Thanks for pointing this out.