Re: Is physname mangled or not? (PR c++/8216)

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Tue, 03 May 2011 20:58:49 +0200, Ulrich Weigand wrote:
>  - 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

 <1><55>: Abbrev Number: 6 (DW_TAG_class_type)
    <56>   DW_AT_name        : (indirect string, offset: 0xb): C<int>
 <2><61>: Abbrev Number: 7 (DW_TAG_subprogram)
    <63>   DW_AT_name        : C
    <68>   DW_AT_declaration : 1
    <69>   DW_AT_object_pointer: <0x71>
 <3><71>: Abbrev Number: 4 (DW_TAG_formal_parameter)
    <72>   DW_AT_type        : <0x80>
    <76>   DW_AT_artificial  : 1
 <2><78>: Abbrev Number: 8 (DW_TAG_template_type_param)
    <79>   DW_AT_name        : T
    <7b>   DW_AT_type        : <0x119>
(less important attributes removed).

This is IMO a GCC debug/ bug, shouldn't <63> DW_AT_name be `C<int>'?


>  - 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) ...

This physname change broke more issues, thanks for finding this one.
The change I described in the bottom patch of:
	Re: [RFA] Typedef'd method parameters [2/4]
	http://sourceware.org/ml/gdb-patches/2011-04/msg00524.html
that is the part:
	The mangled symbol name is not available for full symbols.  */
	 #define SYMBOL_LINKAGE_NAME(symbol)	(symbol)->ginfo.name
Although a similar comment should be now also at:
	TYPE_FN_FIELD_PHYSNAME
The other physname regressions of belonging to this no-longer-mangled category:
	New: regression by physname: PE32 prologue skip vs. static initializers
	http://sourceware.org/bugzilla/show_bug.cgi?id=12680
	New: physname regression: set print demangle off
	http://sourceware.org/bugzilla/show_bug.cgi?id=12707


> So I guess my question is, how is this supposed to work?  Should
> is_constructor_name accept demangled names?

It cannot - it does not know the type name, does it?


> Should there be some generic routine that instead tests a demangled name for
> whether it is a constructor (or destructor)?

With a GCC debug/ fix it should work.  Do you agree with its filing?


Thanks,
Jan