Slow handling of C++ symbol names
Michael Elizabeth Chastain
mec.gnu@mindspring.com
Wed Dec 3 16:48:00 GMT 2003
Ian Lance Taylor writes:
> Could you extract a few of the larger demangled names from each version,
> and post them? It might be a good double-check that something isn't
> weirdly broken.
I'm working on it.
I'm writing a Perl script to pass each name through both demanglers,
strip the differences, and compare the results. There are a lot of
picky differences to account for.
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.
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.
Michael C
More information about the Gdb
mailing list