Is physname mangled or not? (PR c++/8216)
Jan Kratochvil
jan.kratochvil@redhat.com
Wed May 4 17:57:00 GMT 2011
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
More information about the Gdb-patches
mailing list