This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb 5.2.1?
- From: Stephane Carrez <stcarrez at nerim dot fr>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: Andrew Cagney <ac131313 at ges dot redhat dot com>, gdb at sources dot redhat dot com
- Date: Sat, 29 Jun 2002 01:46:21 +0200
- Subject: Re: gdb 5.2.1?
- References: <3D1A79F4.7000108@ges.redhat.com> <nplm912u9m.fsf@zwingli.cygnus.com>
Hi!
Jim Blandy wrote:
Andrew Cagney <ac131313@ges.redhat.com> writes:
No I've not forgotten. Just a little distracted :-(
If anyone knows of a bug or fix they want in 5.2.1 then please see
about pulling it in during the next 24 hrs.
I wish GDB didn't use so much memory. If you could pull that in
during the next 24 hours, that would be incredibly great.
So do I!
For a big C++ program gdb's process goes above 100Mb and increases by 350Mb
each time I do a 'call foo()'. Pretty unusable (it's also incredibly slow).
Interestingly it seems only bound to calling a function from gdb.
I found this in stabsread.c (and it is one place that allocates some
memory while I see my pb).
/* If this symbol is from a C++ compilation, then attempt to cache the
demangled form for future reference. This is a typical time versus
space tradeoff, that was decided in favor of time because it sped up
C++ symbol lookups by a factor of about 20. */
SYMBOL_INIT_DEMANGLED_NAME (sym, &objfile->symbol_obstack);
Can this be deactivated?
(For a test I mean).
Stephane
-----------------------------------------------------------------------
Home Office
E-mail: stcarrez@nerim.fr Stephane.Carrez@solsoft.fr
WWW: http://stephane.carrez.free.fr http://www.solsoft.com
Free the Software! Visual Security Policy Management