From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-15637-listarch-gdb-patches=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 22326 invoked by alias); 16 May 2002 23:53:02 -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 22310 invoked from network); 16 May 2002 23:53:00 -0000
Received: from unknown (HELO cygnus.com) (205.180.83.203)
  by sources.redhat.com with SMTP; 16 May 2002 23:53:00 -0000
Received: from localhost.redhat.com (romulus.sfbay.redhat.com [172.16.27.251])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA11197;
	Thu, 16 May 2002 16:52:11 -0700 (PDT)
Received: by localhost.redhat.com (Postfix, from userid 469)
	id 23B7110FC9; Thu, 16 May 2002 19:51:39 -0400 (EDT)
From: Elena Zannoni <ezannoni@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15588.17930.984005.87068@localhost.redhat.com>
Date: Thu, 16 May 2002 16:53:00 -0000
To: Jim Blandy <jimb@redhat.com>
Cc: Daniel Jacobowitz <drow@mvista.com>, Elena Zannoni <ezannoni@redhat.com>,
        gdb-patches@sources.redhat.com
Subject: Re: [RFA] [4/5] Use DWARF-2 DW_AT_artificial information
In-Reply-To: <np661nu3hu.fsf@zwingli.cygnus.com>
References: <20020115153157.A28714@nevyn.them.org>
	<20020307154311.A19496@nevyn.them.org>
	<20020514211335.GA11766@nevyn.them.org>
	<15585.58783.368594.458392@localhost.redhat.com>
	<20020515045247.GA14330@nevyn.them.org>
	<15586.42427.974873.473657@localhost.redhat.com>
	<20020515185143.GA31364@nevyn.them.org>
	<np661nu3hu.fsf@zwingli.cygnus.com>
X-SW-Source: 2002-05/txt/msg00685.txt.bz2

Jim Blandy writes:
 > 
 > Possibly clueless suggestion:
 > 

I think this is where Daniel was headed, he's the one that added that
'artificial' member. Except he ran into an HP merge roadblock.

Elena


 > Couldn't we represent a method's arguments the same way we represent a
 > function's arguments?  That is, nfields would carry the number of
 > arguments, and fields[i] would describe the n'th field.  We could use
 > the `artificial' member of `union field_location' in `struct field' to
 > hold the information conveyed by DW_AT_artificial.
 > 
 > The fact that we've distinguished these has caused problems in the
 > past.  Check out the following code in hand_function_call:
 > 
 >   for (i = nargs - 1; i >= 0; i--)
 >     {
 >       /* Assume that methods are always prototyped, unless they are off the
 > 	 end (which we should only be allowing if there is a ``...'').  
 >          FIXME.  */
 >       if (TYPE_CODE (ftype) == TYPE_CODE_METHOD)
 > 	{
 > 	  if (i < n_method_args)
 > 	    args[i] = value_arg_coerce (args[i], TYPE_ARG_TYPES (ftype)[i], 1);
 > 	  else
 > 	    args[i] = value_arg_coerce (args[i], NULL, 0);
 > 	}
 > 
 >       /* If we're off the end of the known arguments, do the standard
 >          promotions.  FIXME: if we had a prototype, this should only
 >          be allowed if ... were present.  */
 >       if (i >= TYPE_NFIELDS (ftype))
 > 	args[i] = value_arg_coerce (args[i], NULL, 0);
 > 
 >       else
 > 	{
 > 	  param_type = TYPE_FIELD_TYPE (ftype, i);
 > 	  args[i] = value_arg_coerce (args[i], param_type, TYPE_PROTOTYPED (ftype));
 > 	}
 > 
 > Those two loops could be re-collapsed into one.