From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30828 invoked by alias); 6 Jan 2004 02:51:02 -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 30819 invoked from network); 6 Jan 2004 02:51:01 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 6 Jan 2004 02:51:01 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AdhJ6-0001jo-Ah; Mon, 05 Jan 2004 21:51:00 -0500 Date: Tue, 06 Jan 2004 02:51:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc/cp] method stub assertions Message-ID: <20040106025100.GA6543@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com References: <20040106001215.5CD314B35A@berman.michael-chastain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040106001215.5CD314B35A@berman.michael-chastain.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00129.txt.bz2 On Mon, Jan 05, 2004 at 07:12:15PM -0500, Michael Chastain wrote: > Hi Daniel, > > > Right now we assume that methods have a TYPE_DOMAIN_TYPE. This patch > > pushes more knowledge of limited debug readers out into the rest of > > GDB. I'd rather go the other direction - set a domain type. > > I'm going to push back on this and argue that a C++ method should > not need to have a domain type. > > A pointer-to-member needs to have a domain type because it's > explicitly associated with a domain: > > int (A::*PMF)(int); > > The debug information for "PMF" says that it's in class A, > and that becomes the domain type. It's all good. > > But an ordinary member does not need to have a domain: > > class A > { > static int foo (int); > }; > > class B > { > static int bar (int); > }; > > static int bletch (int); > > Here, the types of "foo", bar", and "bletch" are exactly the same. > Adding a "domain A" to the first and "domain B" to the second > makes them not the same, and will cause me a big problem. Those are static methods. Don't confuse them with normal methods! They're basically just functions that live in a class. I don't know whether or not offhand they need to have a domain type. Probably right now they do, but I'd be amenable to changing that. > In HP debug format, the DNTT records for A::foo, B::bar, and bletch can > be the same record. hp-read.c has a 1-1 map from DNTT records to gdb > types. This is the dntt_type_vector in 'struct hpread_symfile_info'. > > When the HP reader sees a DNTT type, it autovivifies dntt_type_vector > and uses the dntt_type_vector[hp_type.dnttp.index] for the gdb type. > So the same DNTT type always maps to the same gdb type, > and all three functions can share a type entry. > > But different DNTT type will need to have different gdb types because > they have different domain types. That means I have to mess with a lot > of code that translates DNTT types: (1) pass in context information that > is not part of the DNTT record to begin with, and (2) change the > dntt-to-gdbtype mapping array to index off of [domain type, index] > instead of just [index]. > > All of this for a field which is not used in expression evaluation > anyways! Do class A { int bar (int); } and class B { int baz (int); } have the same DNTT type? If they do, then aCC is so hideously busted that I don't know what to do. Wait a sec... this doesn't make sense... if the domain type is only needed for non-static members we could just get it from the first argument.... something is wrong here. > c_type_print_varspec_prefix does contain this code: > > case TYPE_CODE_METHOD: > if (passed_a_ptr) > fprintf_filtered (stream, "("); > c_type_print_varspec_prefix (TYPE_TARGET_TYPE (type), stream, show, 0, 0); > if (passed_a_ptr) > { > fprintf_filtered (stream, " "); > c_type_print_base (TYPE_DOMAIN_TYPE (type), stream, 0, passed_a_ptr); > fprintf_filtered (stream, "::"); > } > break; > > However, I don't think it's actually possible to have a C++ type which > is a pointer to a TYPE_CODE_METHOD. If the C++ type is "pointer to > function returning int", it can point to a non-method function or to a > static method function. If the C++ type is "pointer to class method > returning int", then that is a pointer-to-member, and a > > pointer-to-member is already required to have a class type > along with the method signature. I believe you can create a pointer to TYPE_CODE_METHOD in GDB even though it is not meaningful C++; just take the thing's address. I could be mistaken about that however. > How about it, can you re-think your requirement that each method > type has a domain type? Do static methods have TYPE_CODE_METHOD, and should they? That's the question. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer