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

[Jim Blandy <jimb@zwingli.cygnus.com>]

(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?