Re: Debugging a large program

[Andrew Cagney <cagney at gnu dot org>]

> On Mon, Oct 04, 2004 at 01:44:55PM -0700, Nick Savoiu wrote:
>
> > > Hi,
> > >
> > > I'm using GDB to debug a rather large program and I'm running into memory
> > > usage problems that slow down debugging considerably. Just invoking GDB on
> > > the executable (without issuing 'run') results in GDB using up 450MB of
> > > memory.
> > >
> > > I think that this is caused by GDB reading in all the symbol info. However,
> > > the code that I'm debugging uses but a small fraction of the code that's
> > > present in the program. Can I somehow tell GDB to only load the symbols it
> > > needs?

Tell me about it :-)

> GDB already reads in only what it needs, and more lazily - however,
> there's some information about every symbol that's needed.  450MB is
> pretty remarkable; how big is the application?  readelf -S output would
> be the best way to answer the question.

This, unfortunatly, isn't true.  The "classic" user interaction:
	gdb ...
	run
	<segmentation fault>
	backtrace
	print variable
involves very few symbols and addresses yet GDB is slurping all the 
following:

- entire minsymtab - O(<nr minsyms>) at least

- simplified symtab a.k.a. partial-symtab - O(<nr syms>) at least

and then when the first symbol request occures:

- full symtab - O(<nr syms>) at least

- address information - O(<?>) (or is this done above?)

GDB needs to find ways to achieve (assuming co-operation from GCC and 
BFD) an initial:

- process symtab sections (for address ranges) - O(<nr sections>)

and then when a symbol is requested:

- lookup symbol - O(log (<nr symbols>)) * O(<nr solibs>) for first time 
(better?); O(1) for re-searches

Doing this means abandoning the psymtab and instead having symbol code 
directly read each symbol or address as it is needed, and with the 
minimum auxulary information (i.e., direct from disk).

The first time I made this observation, the response was "impossible", 
the second time "hard".  I guess I'm making progress :-)

Andrew