From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7546 invoked by alias); 18 Sep 2004 00:14:23 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7523 invoked from network); 18 Sep 2004 00:14:20 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 18 Sep 2004 00:14:20 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1C8Srr-0003u7-TI; Fri, 17 Sep 2004 20:14:20 -0400 Date: Sat, 18 Sep 2004 00:14:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: representing C++ constructors in GDB's symbol tables Message-ID: <20040918001419.GA14972@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-09/txt/msg00154.txt.bz2 On Fri, Sep 17, 2004 at 05:45:40PM -0500, Jim Blandy wrote: > > There are currently several problems I see in the way we represent C++ > constructors in GDB's symbol table. > > First, for a class named "X", we put three (or possibly four) entries > in VAR_DOMAIN all named "X": the typedef, and two (or possibly three) > constructors. This makes it (cough) difficult to look up the one you > need. > > It occured to me that perhaps constructors should not be in the > VAR_DOMAIN. You can't use them by name in expressions: you have to > say "new X(...)", never "X(...)". You can't call them directly. You > can't take their addresses: "&X::X(int)" is not valid C++. The only > reason they really have names at all is to let you define them outside > the class. > > Creating a new CONSTRUCTORS_DOMAIN would give you something reasonable > to pass when handling a "new" expression. And there's nothing wrong > with adding a C++-specific domain; domains were created to distinguish > the different roles identifiers might play in a particular language: > witness STRUCT_DOMAIN vs VAR_DOMAIN for C. I prefer fixing the names of the constructors in the symbol table (or un-flattening the symbol table); I think that would obsolete this. > Then there's the question of duplicate copies of the constructors > themselves. The code at the moment wants to distinguish them by their > physical (linker) names, but I gather one of the main thrusts of David > and Daniel's work was to move away from the internal use of mangled > names for this kind of thing. Domains are the wrong tool there; the > presence of multiple constructor copies is an ABI-specific thing. > I don't have an answer to that that sounds good yet. We only need to have textual names that distinguish these things for the user interface. Internally, they can just be different pointers; that means we have to keep track of them from the types rather than storing names in the types and abusing lookup_symbol. -- Daniel Jacobowitz