From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21572 invoked by alias); 14 Jun 2002 00:36:23 -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 21565 invoked from network); 14 Jun 2002 00:36:21 -0000 Received: from unknown (HELO nevyn.them.org) (66.19.120.58) by sources.redhat.com with SMTP; 14 Jun 2002 00:36:21 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17If59-0005cu-00; Thu, 13 Jun 2002 20:36:51 -0400 Date: Thu, 13 Jun 2002 17:36:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Switch TYPE_CODE_METHOD to store arguments like TYPE_CODE_FUNCTION Message-ID: <20020614003650.GA21505@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <20020604024456.GA8733@branoic.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-06/txt/msg00236.txt.bz2 On Thu, Jun 13, 2002 at 06:35:59PM -0500, Jim Blandy wrote: > > Minor observation: > > In gdbtypes.h, your patch makes the following change to `struct field': > > /* Name of field, value or argument. > - NULL for range bounds and array domains. */ > + NULL for range bounds, array domains, and member function > + arguments. */ > > char *name; > > Is there any reason this *must* be null? Aren't there times where we > do know a method's arguments' names, and where we could fill this in? > > I guess I'm thinking about the way prototyped function types in C may > or may not include the names: > > typedef int (*foo_t) (int x, int y); > typedef int (*bar_t) (int, int); > typedef int (*baz_t) (int x, int); > > Is there any analog to this in C++? Right now, we have two entries for a method. One of them is at declaration time and comes from the class; the other is at definition time and comes from the function itself. One is TYPE_CODE_METHOD and names are not present in the debug info for either stabs or dwarf; the other is TYPE_CODE_FUNCTION. Until we unify those (some day...) we won't have the names. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer