This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Is physname mangled or not? (PR c++/8216)
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: gdb-patches at sourceware dot org
- Date: Tue, 3 May 2011 20:58:49 +0200 (CEST)
- Subject: Is physname mangled or not? (PR c++/8216)
Hello,
PR c++/8216 says:
When doing ptype on a templated class, GDB will print
out constructors as having a return type of void
instead of as having no return type at all.
Code in c-typename.c:c_type_print_base does this in an attempt
to determine whether a method is a constructor:
char *method_name = TYPE_FN_FIELDLIST_NAME (type, i);
char *name = type_name_no_tag (type);
int is_constructor = name && strcmp (method_name,
name) == 0;
for (j = 0; j < len2; j++)
{
char *physname = TYPE_FN_FIELD_PHYSNAME (f, j);
int is_full_physname_constructor =
is_constructor_name (physname)
|| is_destructor_name (physname)
|| method_name[0] == '~';
[...]
else if (!is_constructor /* Constructors don't
have declared
types. */
&& !is_full_physname_constructor /* " " */
&& !is_type_conversion_operator (type, i, j))
So basically this says: a method is a constructor if either:
- the method name equals the type name, or
- the C++ ABI routine says the physname is a constructor
and, a method is a destructor if either:
- the method name starts with a ~, or
- the C++ ABI routine says the physname is a destructor
I'm not quite sure why we need those duplicate checks, but in
any case for the constructor they both fail:
- For template classes, the method name of a constructor does
*not* contain the template instance type list, while the type
name does, and thus the strcmp fails
- The is_constructor_name C++ ABI callback actually fails
*always*. This is because it works only if it gets a
*mangled* name as input, but TYPE_FN_FIELD_PHYSNAME returns
a demangled name (at least with dwarf2read.c) ...
(For destructors, this problem doesn't apply since the ~ test
catches just about everything. I'm just wondering why we still
try to do the is_destructor_name (physname) check as well ...)
This latter seems to have been due to a deliberate change of
physname: dwarf2read now always sets this to a demangled name,
while e.g. stabsread sets it to a mangled name.
So I guess my question is, how is this supposed to work? Should
is_constructor_name accept demangled names? Should there be some
generic routine that instead tests a demangled name for whether
it is a constructor (or destructor)?
Any suggestions to fix this would be appreciated ...
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com