From: Daniel Berlin <dan@cgsoftware.com>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: Daniel Berlin <dan@cgsoftware.com>, gdb@sources.redhat.com
Subject: Re: improving psymtab generation memory usage
Date: Wed, 18 Jul 2001 22:34:00 -0000 [thread overview]
Message-ID: <87ae21bhyg.fsf@cgsoftware.com> (raw)
In-Reply-To: <20010718225933.4186C5E9D8@zwingli.cygnus.com>
Jim Blandy <jimb@zwingli.cygnus.com> writes:
> I think you mentioned a while back that it was possible to greatly
> reduce the amount of memory GDB used generating partial symbol tables
> from Dwarf 2 debug info. (Or is that just confabulation on my
> part?)
Yup.
I also did it for symtabs.
> Can you explain again the approach you suggested?
Sure.
I gave up on playing language specific games, and now just MD5 the
partial (and full die) attributes (for partial, we md5 the tag, name,
lowpc, and highpc), we keep a splay tree of md5 checksums, and skip
any dies (and their children) at the top level if it's md5 is in the
tree.
You'd have to have something at the same name, same tag, same
namespace, and same location in memory for the partial die to match.
I don't think that's possible unless they are the same thing.
Certainly, GDB wouldn't know what to do with two things with the same
address and name, and same namespace.
That's all our partial symbols have.
For full die's, we process all attributes but the sibling attribute.
So they'd have to have the same cu relative offsets for the
attributes location attributes (I.E. The DW_AT_type for a variable would
have to be at the same offset in the CU for both cases) , etc, in
order to be the
same. Luckily, because gcc defers output, they end up with the same
cu relative offsets if they processed the include files in the same
order.
So while you'd think we'd never get any duplicates this way, we
eliminate just about all of them.
:)
MD5 can be done at over 30 meg a second on a pentium 90, so speed is
not a concern. It doesn't show up on profiles.
--Dan
--
"I was once arrested for walking in someone else's sleep.
"-Steven Wright
next prev parent reply other threads:[~2001-07-18 22:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-18 15:58 Jim Blandy
2001-07-18 22:34 ` Daniel Berlin [this message]
2001-07-19 8:43 ` Jim Blandy
2001-07-19 8:52 ` Daniel Berlin
2001-07-19 9:48 ` Jim Blandy
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=87ae21bhyg.fsf@cgsoftware.com \
--to=dan@cgsoftware.com \
--cc=gdb@sources.redhat.com \
--cc=jimb@zwingli.cygnus.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