gdb 5.2.1?

[Stephane Carrez]

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