This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Slow handling of C++ symbol names
- From: mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)
- To: ian at wasabisystems dot com, mec dot gnu at mindspring dot com
- Cc: ac131313 at redhat dot com, drow at mvista dot com, gdb at sources dot redhat dot com,wcohen at redhat dot com
- Date: Wed, 3 Dec 2003 11:47:34 -0500 (EST)
- Subject: Re: Slow handling of C++ symbol names
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