From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7879 invoked by alias); 17 Sep 2004 22:46:55 -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 7863 invoked from network); 17 Sep 2004 22:46:51 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 17 Sep 2004 22:46:51 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8HMkogK003413 for ; Fri, 17 Sep 2004 18:46:50 -0400 Received: from zenia.home.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8HMkir26807; Fri, 17 Sep 2004 18:46:45 -0400 To: gdb@sources.redhat.com Subject: representing C++ constructors in GDB's symbol tables From: Jim Blandy Date: Fri, 17 Sep 2004 22:46:00 -0000 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-09/txt/msg00150.txt.bz2 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. 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.