Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jason Molenda <jason-swarelist@molenda.com>
To: Andrew Cagney <cagney@gnu.org>
Cc: Daniel Jacobowitz <drow@false.org>,
	Nick Savoiu <savoiu@ics.uci.edu>,
	gdb@sources.redhat.com
Subject: Re: Debugging a large program
Date: Fri, 08 Oct 2004 21:35:00 -0000	[thread overview]
Message-ID: <20041008121611.A90098@molenda.com> (raw)
In-Reply-To: <F51E79B1-195C-11D9-ACAD-000A9569836A@gnu.org>; from cagney@gnu.org on Tue, Oct 05, 2004 at 10:02:14AM -0400

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


       reply	other threads:[~2004-10-08 19:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <F51E79B1-195C-11D9-ACAD-000A9569836A@gnu.org>
2004-10-08 21:35 ` Jason Molenda [this message]
2004-10-11  1:46   ` Daniel Berlin
2004-10-11  6:10     ` Andrew Cagney
2004-10-11 13:59   ` Andrew Cagney
2004-10-04 21:15 Nick Savoiu
2004-10-04 21:16 ` Daniel Jacobowitz
2004-10-04 23:21   ` Daniel Jacobowitz
2004-10-04 23:25     ` Nick Savoiu
2004-10-05  5:24       ` Daniel Jacobowitz
2004-10-05 15:26         ` Nick Savoiu
  -- strict thread matches above, loose matches on Subject: below --
2004-10-04 20:48 Nick Savoiu
2004-10-04 20:54 ` Daniel Jacobowitz
2004-10-05 14:05   ` Andrew Cagney
2004-10-05 14:07     ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041008121611.A90098@molenda.com \
    --to=jason-swarelist@molenda.com \
    --cc=cagney@gnu.org \
    --cc=drow@false.org \
    --cc=gdb@sources.redhat.com \
    --cc=savoiu@ics.uci.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox