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: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: Will Cohen <wcohen at redhat dot com>, gdb at sources dot redhat dot com
- Date: Thu, 20 Nov 2003 11:19:15 -0500
- Subject: Re: Slow handling of C++ symbol names
- References: <3FBBDC27.50204@redhat.com> <20031119211355.GA31069@nevyn.them.org> <3FBCE71B.7060100@redhat.com>
On Thu, Nov 20, 2003 at 11:08:59AM -0500, Andrew Cagney wrote:
> >
> >Have you tried a more recent version of GDB? This may have been
> >improved. Definitely some startup time issues were fixed.
>
> Nothing in the ChangeLogs jumped out.
Well, I remember fixing some startup time issues since then :P For
instance, the cache shared between minimal and partial symbols should
cut demangling time about in half.
> >Also, the demangler actually comes from GCC, not GDB.
>
> I don't see GCC being motivated to fix it though :-(
>
> > All we can do is
> > try to call it less often.
>
> Which leads to the question. Why does GDB demangle symbols? My
> simplistic understanding of the code is that GDB only needs the "iw"
> (a.k.a., demangled string up to but excluding the lparen and ignoring
> white space) part of the symbol in the search table (the rest isn't so
> critical and can be constructed on-demand).
A substantial amount of demangling is needed to produce the part of
the symbol before the lparen; consider templates. Also, we need the
full names in the minimal symbol for break 'foo(int)' with quotes to
work. And there are assumptions of unique symbol names in our
hashing/searching, IIRC.
I'm sure there are tricks we can do to cut down on how early or often
we demangle, but it still seems to be necessary.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer