Re: Slow handling of C++ symbol names

[Ian Lance Taylor <ian@wasabisystems.com>]

mec.gnu@mindspring.com (Michael Elizabeth Chastain) writes:

> So far I've found one type of difference that looks like a bug in the
> new demangler.
> 
>   _ZStltI9file_pathSsEbRKSt4pairIT_T0_ES6_
>   OLD: bool std::operator< <file_path, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::pair<file_path, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&, std::pair<file_path, std::basic_string<char, > std::char_traits<char>, std::allocator<char> > > const&)
>   NEW: bool std::operator<<file_path, std::string>(std::pair<file_path, std::string> const&, std::pair<file_path, std::string> const&)
> 
> The old demangler produces "operator< <", and the new demangler produces
> "operator <<".  I'm not a name mangling expert but I think that
> "operator <" is correct here and the new demangler suffers from
> shift-operator-versus-template-syntax gotcha.

Whoops.  Quite right.

The old name you list above was generated using DMGL_VERBOSE.  I can
tell by use of std::basic_string<char, std::char_traits<char>,
std::allocator<char> > where the new demangler just uses std::string.
The old demangler generates the former with DMGL_VERBOSE, or
std::string without DMGL_VERBOSE.

If the old demangler is being run with DMGL_VERBOSE, then I'm not
surprised that the resulting strings are much larger.  That was the
main thing which concerned me, since I didn't see anything in gdb
which passed DMGL_VERBOSE to the demangler.

> Also, why do you want the demangled names?  I would think you would
> have the same old+new demanglers that I do, so that the mangled names
> would suffice.  My reason is that the mangled names which are different
> amount to 3 megabytes or so, but the demangled names which are different
> amount to 300 megabytes or so.

Oh sure, for some reason I thought it was easier for you to send the
demangled names.  Doesn't make much sense, I guess.  The mangled names
are fine.

Ian