From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19648 invoked by alias); 6 Jan 2004 18:24:07 -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 19641 invoked from network); 6 Jan 2004 18:24:06 -0000 Received: from unknown (HELO smtp6.mindspring.com) (207.69.200.110) by sources.redhat.com with SMTP; 6 Jan 2004 18:24:06 -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 1Advrd-0008SJ-00; Tue, 06 Jan 2004 13:23:37 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 32BCA4B35A; Tue, 6 Jan 2004 13:23:58 -0500 (EST) To: drow@mvista.com Subject: Re: [rfc/cp] method stub assertions Cc: gdb-patches@sources.redhat.com Message-Id: <20040106182358.32BCA4B35A@berman.michael-chastain.com> Date: Tue, 06 Jan 2004 18:24:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-01/txt/msg00142.txt.bz2 > 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. 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. > 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 ? > 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