This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Debugging a large program


On Tue, Oct 05, 2004 at 10:02:14AM -0400, Andrew Cagney wrote:

> 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).



For what it's worth, we've been working on a less ambitious scheme
at Apple for the past month, with similar benefits.

We've had code in our gdb where the user can set "load rules" which
specify how much gdb will know about the solibs that are loaded,
e.g.  nothing, address ranges only, minsyms, normal debug handling.
Jim has added code so we can treat everything at the minsym level
by default, and when we're looking up one of those symbols or we're
in an address contained by that solib, we read in the psymtabs for
that solib and let gdb do its usual thing.  e.g. when you hit a 
breakpoint or interrupt execution and do a backtrace, the psymtabs
for all the solibs containing functions in the stack are read in;
the relevant psymtabs are upgraded to symtabs as they normally would
as needed.

The amount of changes was not especially large given the "object
file load level" code already being present.

The only drawback to our approach is that static functions aren't
known to gdb when they're in a minsym-level solib -- so a user
putting a breakpoint on a static function will fail unless something
else in that solib has caused it to be psymtab'ed already.  We're
only using this delayed symbol reading optimization when the Xcode
UI is used, though, so we can mitigate that problem through some
clever UI.

Andrew's approach is much cooler, but it's definitely not something
that could be done with stabs (as it exists today), and we're stuck
on stabs on MacOS X for a while still.

Anyway, just a point of information.  It was a HUGE win for us on
extremely large applications where they have many large solibs and
the developer is only debugging code in a couple of them.

J


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]