Re: [WIP] New dwarf2 reader - updated 07-02-2001

Jim Blandy
2001-07-30T17:07:00Z

(I moved last week; finally have time to look at the new reader.)

Here are some questions that came to mind on first reading. I haven't
read everything thoroughly yet, so I could well be just
misunderstanding what's going on.

- MD5 generates a 128-bit checksum. Any reason you only use the first
32 bits in your hash? It looks like checksum_die and
checksum_partial_die both cut it off at eight digits.

- Why are you using a splay tree keyed by MD5 hash values, instead of
a hash table? The only advantage of a splay over a hash table is
ordered retrieval, but your keys don't have any meaningful order.

- By using the MD5 checksum as your search key, you're guaranteed to
lose if you get an MD5 collision. I agree that a collision is very
unlikely (or would be, if you were using all 128 bits), but it seems
icky.

- Assuming MD5 is perfect, you don't checksum all attribute forms
(DW_FORM_flag, for example). This means that you can get false
duplicates, if two dies differ only in (say) a flag's value. How is
read_comp_unit_dies set up to tolerate that?

- You never clear dwarf2_symbol_splay. This might be okay if you
checksummed the complete contents of the die (I'm not sure about
that), but you don't include block contents in the checksum ---
process_attribute includes the pointer to the `struct dwarf2_block'
in the checksum, not the block's actual contents. So if we have two
dies which differ only in their block contents, and the `struct
dwarf2_block' objects which hold those contents happen to get
allocated at the same address, by different calls to
dwarf2_psymtab_to_symtab, you'll get a false match again.

- In read_comp_unit_dies, when you find a duplicate die, you skip to
its sibling. What if the parent die is identical, but the children
dies differ?

Can you set me straight on this stuff?