From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10720 invoked by alias); 6 Jan 2004 19:02:31 -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 10709 invoked from network); 6 Jan 2004 19:02:27 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 6 Jan 2004 19:02:27 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AdwSw-0002MS-LY; Tue, 06 Jan 2004 14:02:10 -0500 Date: Tue, 06 Jan 2004 19:02:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc/cp] method stub assertions Message-ID: <20040106190209.GA9422@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com References: <20040106182358.32BCA4B35A@berman.michael-chastain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040106182358.32BCA4B35A@berman.michael-chastain.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00145.txt.bz2 On Tue, Jan 06, 2004 at 01:23:58PM -0500, Michael Chastain wrote: > > That's a nice hypothesis. Unfortunately it's completely wrong :) > > First of all, TYPE_CODE_MEMBER and TYPE_CODE_METHOD are siblings. > > MEMBER is used for data variables, not to wrap methods. > > I think you mean: TYPE_CODE_MEMBER is used for pointers to data > members. Blah, no, it's supposed to be used for both pointer-to-member and pointer-to-member-function. You're right. > It's a really bad name. How about: > > TYPE_CODE_PTR # pointer to memory > TYPE_CODE_PMD # pointer to member data > TYPE_CODE_PMF_PLAIN # pointer to non-static non-virtual function > TYPE_CODE_PMF_VIRTUAL # pointer to virtual function > > TYPE_CODE_PTR has a raw CORE_ADDR, just like it does now. > TYPE_CODE_PMD has a class type and a data offset. > TYPE_CODE_PMF_PLAIN has a class type and a raw CORE_ADDR. > TYPE_CODE_PMF_VIRTUAL has a class type and a vtbl offset. No. None of this are necessary. The details of how a pointer-to-member work should never be exposed to the GDB type machinery; it's just a pointer-to-member, leave it at that. If you want to be able to call through them use the DWARF-2 location expression machinery and DW_AT_use_location. > > The debug information for A::bad6 does not specify that it is a method. > > Rather only the debug info for class A specifies that it has a method > > named A::bad6. Take a look at a readelf -wi dump of your testcase to > > see how this works. > > Ouch. > > How can we make &A::bad6 have a different type than &f1 ? As I suggested in my last message, by making A::bad6 have a different type than f1. > > Currently they do appear as TYPE_CODE_METHOD. I think that they > > probably shouldn't. A pointer to a static method is a function > > pointer, not a pointer-to-member. Similarly static variables should > > probably not be TYPE_CODE_MEMBER. > > I agree that &A::static_function should be TYPE_CODE_PTR. > It's easy to figure that out even if A::static_function is > TYPE_CODE_METHOD, because we can look at TYPE_FLAG_STATIC > at the time we evalue the "&" operator. > > Michael C > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer