This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [WIP] New dwarf2 reader - updated 07-02-2001
- To: Daniel Berlin <dan at cgsoftware dot com>
- Subject: Re: [WIP] New dwarf2 reader - updated 07-02-2001
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- Date: 30 Jul 2001 19:08:17 -0500
- Cc: gdb-patches at sources dot redhat dot com
- References: <878zi7dymh.fsf@cgsoftware.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?