From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Jim Blandy Cc: Daniel Berlin , gdb@sources.redhat.com Subject: Re: improving psymtab generation memory usage Date: Wed, 18 Jul 2001 22:34:00 -0000 Message-id: <87ae21bhyg.fsf@cgsoftware.com> References: <20010718225933.4186C5E9D8@zwingli.cygnus.com> X-SW-Source: 2001-07/msg00268.html Jim Blandy 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