From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15923 invoked by alias); 6 Jan 2004 00:12:26 -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 15908 invoked from network); 6 Jan 2004 00:12:25 -0000 Received: from unknown (HELO smtp6.mindspring.com) (207.69.200.110) by sources.redhat.com with SMTP; 6 Jan 2004 00:12:25 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1AdepB-0004t1-00; Mon, 05 Jan 2004 19:11:57 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 5CD314B35A; Mon, 5 Jan 2004 19:12:15 -0500 (EST) To: drow@mvista.com Subject: Re: [rfc/cp] method stub assertions Cc: gdb-patches@sources.redhat.com Message-Id: <20040106001215.5CD314B35A@berman.michael-chastain.com> Date: Tue, 06 Jan 2004 00:12:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-01/txt/msg00122.txt.bz2 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. 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! 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. How about it, can you re-think your requirement that each method type has a domain type? Michael C