From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6834 invoked by alias); 7 Jan 2013 19:11:44 -0000 Received: (qmail 6809 invoked by uid 48); 7 Jan 2013 19:11:43 -0000 From: "dblaikie at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug c++/14998] GDB cannot handle pointer to member functions being encoded with DW_TAG_ptr_to_member_type Date: Mon, 07 Jan 2013 19:11:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dblaikie at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2013-q1/txt/msg00029.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14998 --- Comment #7 from David Blaikie 2013-01-07 19:11:41 UTC --- > I was expecting the subroutine type to have an artificial parameter > for the "this" pointer. Your reading of the DWARF is correct. Clang currently doesn't emit the 'this' parameter. The DWARF standard is a bit vague on this: "The pointer to member entry has a DW_AT_type attribute to describe the type of the class or structure member to which objects of this type may point." but it seems like if the DW_AT_type of a pointer-to-member variable "int foo::*x;" is simply "int", then the DW_AT_type of a pointer-to-member function "int (foo::*x)(float)" would be "int(float)". > I think if that was added then calling would work. Curious - I could try this, though it's a little non-trivial to construct that artificial type in Clang. If it works, though, then I'd consider this bug to be lower priority but still 'nice to have' (essentially GDB would detect whether the first parameter is artificial (& the same type as the DW_AT_containing_type) & if so, use that, otherwise insert such a parameter based on the DW_AT_containing_type if that's the representation it prefers). What are your thoughts on this? > Printing the artificial argument appears to be a conscious decision. > From c-typeprint.c: > > Artificial arguments, such as "this" > in non-static methods, are displayed if LINKAGE_NAME is zero > > I think this is a bit weird though. I guess LINKAGE_NAME is DW_AT_MIPS_linkage_name? Though in any case a function pointer won't have a known/fixed name for the function, so I guess it's always 'zero'/always displayed? > I wouldn't mind changing it or perhaps adding a ptype flag to control it. Would there be a need to? It's implied by the containing_type mentioned within the name: int (foo::*)(float) ^^^ Mentioning it again in the parameter list seems redundant. (though I guess some tools might've come to rely on this which might be a justification for keeping it in some form?) -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.