From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29478 invoked by alias); 17 May 2002 04:09:18 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29470 invoked from network); 17 May 2002 04:09:15 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 17 May 2002 04:09:15 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 178Z3T-00056k-00; Fri, 17 May 2002 00:09:23 -0400 Date: Thu, 16 May 2002 21:09:00 -0000 From: Daniel Jacobowitz To: Elena Zannoni Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: [RFA] [4/5] Use DWARF-2 DW_AT_artificial information Message-ID: <20020517040923.GB19263@nevyn.them.org> Mail-Followup-To: Elena Zannoni , Jim Blandy , gdb-patches@sources.redhat.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> <15588.17930.984005.87068@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15588.17930.984005.87068@localhost.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-05/txt/msg00691.txt.bz2 On Thu, May 16, 2002 at 07:51:38PM -0400, Elena Zannoni wrote: > 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. You're thinking too highly of me, but now that you mention it it's a really good idea... I will investigate the practicality of this. I believe it would be a memory increase from where we are now, since we'd allocate a struct field for every argument, but that's not necessarily a bad thing. The simplicity is more important. > > 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. > -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer