Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: David Carlton <carlton@math.stanford.edu>
To: Elena Zannoni <ezannoni@redhat.com>
Cc: Daniel Jacobowitz <drow@mvista.com>, gdb <gdb@sources.redhat.com>,
	Jim Blandy <jimb@redhat.com>
Subject: Re: DW_AT_specification and partial symtabs
Date: Thu, 12 Jun 2003 22:17:00 -0000	[thread overview]
Message-ID: <ro1adcngcv9.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <16104.47067.182016.78574@localhost.redhat.com>

On Thu, 12 Jun 2003 13:26:51 -0400, Elena Zannoni <ezannoni@redhat.com> said:

> I wonder, if we are not reaching the end of the usefulness of the
> psymtabs.  I mean, if we start making the psymtab reader behave like
> the symtab reader, how much faster is that going to be, how much
> smaller, etc. 

Yeah, I'm starting to wonder that, too.  This particular situation is
enough of an edge case that I'm actually tempted not to fix the
psymtab reader until I get bug reports from users complaining about
it, because if I do fix it completely then I'll probably make the
psymtab reader slow, make it duplicate lots and lots of the
functionality of the symtab reader, and do it in such a way as to
cause code duplication that will lead to bugs as the two versions slip
out of sync.  So I'm tempted to let things be for now, and wait until
.debug_pubtypes comes along to save the day.

I guess another possibility would be to merge the symtab reader and
psymtab reader, and have there be some variable 'reading_psyms' or
whatever to control what sort of symbols we're creating, how deeply we
descend into trees, etc.

It would be interesting to find out the following:

1) How much is the savings for building a psymtab vs. building a
   symtab?

2) Where is that savings coming from?

If the savings largely comes from not descending into the bodies of
functions, then the current structure should go: we should just merge
the psymtab and symtab readers, but have some flag floating around
that controls whether or not we descend into bodies of functions.

David Carlton
carlton@math.stanford.edu


  reply	other threads:[~2003-06-12 22:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-12 17:01 David Carlton
2003-06-12 17:05 ` Daniel Jacobowitz
2003-06-12 17:10   ` David Carlton
2003-06-12 17:20   ` Elena Zannoni
2003-06-12 22:17     ` David Carlton [this message]
2003-06-13 13:36       ` Daniel Jacobowitz
2003-06-13 14:00         ` Elena Zannoni
2003-06-13 15:38           ` Andrew Cagney
2003-06-13 15:50             ` Daniel Jacobowitz
2003-06-13 15:57               ` Andrew Cagney
2003-06-13 16:24               ` Andrew Cagney
2003-06-13 16:34                 ` Daniel Jacobowitz
2003-06-17  0:09             ` David Carlton

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=ro1adcngcv9.fsf@jackfruit.Stanford.EDU \
    --to=carlton@math.stanford.edu \
    --cc=drow@mvista.com \
    --cc=ezannoni@redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=jimb@redhat.com \
    /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