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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Wed, 04 May 2011 19:32:43 +0200, Ulrich Weigand wrote:
> Jan Kratochvil wrote:
> +   For full symbols return its demangled form of view of the linker, that is
> +   with typedefs and toplevel const/volatile qualifiers of parameters removed,
> +   for `f(int_typedef const)' it is `f(int)'.  If no typedefs/qualifiers are
> +   in use it's the same as SYMBOL_NATURAL_NAME.  The mangled symbol name is not
> +   available for full symbols.  */
> 
> is not fully accurate either.  As far as I can tell, that *is* true for
> symbols read in by the DWARF reader.  However, for symbols read in by
> the stabs reads (or any of the others), SYMBOL_LINKAGE_NAME still refers
> to the mangled name ...   (Which strikes me as quite odd in the first
> place; how is common code supposed to use this field?)

Thanks for the update.  Yes, SYMBOL_LINKAGE_NAME is somehow broken now for
many use cases, I do not know myself what is the best way out now.


> > With a GCC debug/ fix it should work.  Do you agree with its filing?
> 
> It seems that by now we have agreement that GCC is correct here.

I haven't found in the C++ spec. why it isn't a different way but that is out
of topic here, the truth is the current linkage name is `C<int>::C()'.


> So I guess I see two options remaining:
> 
> - Code a test that compares class name and (demangled) function name, but
>   explicitly removes template instance parameters first

I find it as a good idea.


> - Have the symbol reader call is_constructor_name on the mangled name while
>   it is still available, and store that information somewhere in the type
>   information

The mangled name is never read (processed) from the DWARF file now.


Thanks,
Jan