This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/14998] GDB cannot handle pointer to member functions beingencoded with DW_TAG_ptr_to_member_type


http://sourceware.org/bugzilla/show_bug.cgi?id=14998

--- Comment #7 from David Blaikie <dblaikie at gmail dot com> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]