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]

Re: improving psymtab generation memory usage


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


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