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

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

Daniel Berlin <dan@cgsoftware.com> writes:
> > Using 64 bits, as you intended, is much better, but why not use the
> > full 128?  Honestly, why play this kind of game at all?
> Because it's faster than trying to keep all the die data.
> >  It's not that
> > hard to do the job perfectly --- just use the significant die contents
> > themselves as the tree key.  No collisions, no hash function, simpler.
> >
> 
> Um, think about how much memory that would use.
> We'd have to keep copies of die contents around.

Use the struct die_info objects themselves as the keys, and the
values.  Just define an arbitrary comparison function with the right
semantics.  We need the struct die_info objects around anyway.

> >> > - 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?
> >>
> >> I don't believe this is possible in any language.
> >
> > How about this:
> >
> > namespace X {
> >   namespace A {
> >     int m, n;
> >   }
> > }
> >
> > namespace Y {
> >   namespace A {
> >     int o, p;
> >   }
> > }
> >
> > The dies for the two 'A' namespaces have the name DW_AT_name
> > attribute, but they're clearly different.
> >
> This won't do it, they'll have different decl line attributes.
> And we only eliminate at the top level anyway.

Okay, I hadn't noticed the `nesting_level == 1' test.  This still
isn't okay, though.  Consider the following C program:

    struct {
      int a, b;
    } x;

    struct {
      int c, d;
    } y;

We get the following dies for this, at top level:

        ...

	.byte	0x2	# uleb128 0x2; (DIE (0x5a) DW_TAG_structure_type)
	.long	0x7b	# DW_AT_sibling
	.byte	0x8	# DW_AT_byte_size
	.byte	0x1	# DW_AT_decl_file
	.byte	0x3	# DW_AT_decl_line
	.byte	0x3	# uleb128 0x3; (DIE (0x62) DW_TAG_member)
	.ascii "a\0"	# DW_AT_name
	.byte	0x1	# DW_AT_decl_file
	.byte	0x2	# DW_AT_decl_line
	.long	0x7b	# DW_AT_type
	.byte	0x2	# DW_AT_data_member_location
	.byte	0x23	# DW_OP_plus_uconst
	.byte	0x0	# uleb128 0x0
	.byte	0x3	# uleb128 0x3; (DIE (0x6e) DW_TAG_member)
	.ascii "b\0"	# DW_AT_name
	.byte	0x1	# DW_AT_decl_file
	.byte	0x2	# DW_AT_decl_line
	.long	0x7b	# DW_AT_type
	.byte	0x2	# DW_AT_data_member_location
	.byte	0x23	# DW_OP_plus_uconst
	.byte	0x4	# uleb128 0x4
	.byte	0x0	# end of children of DIE 0x5a
	.byte	0x4	# uleb128 0x4; (DIE (0x7b) DW_TAG_base_type)
	.ascii "int\0"	# DW_AT_name
	.byte	0x4	# DW_AT_byte_size
	.byte	0x5	# DW_AT_encoding
	.byte	0x2	# uleb128 0x2; (DIE (0x82) DW_TAG_structure_type)
	.long	0xa3	# DW_AT_sibling
	.byte	0x8	# DW_AT_byte_size
	.byte	0x1	# DW_AT_decl_file
	.byte	0x7	# DW_AT_decl_line
	.byte	0x3	# uleb128 0x3; (DIE (0x8a) DW_TAG_member)
	.ascii "c\0"	# DW_AT_name
	.byte	0x1	# DW_AT_decl_file
	.byte	0x6	# DW_AT_decl_line
	.long	0x7b	# DW_AT_type
	.byte	0x2	# DW_AT_data_member_location
	.byte	0x23	# DW_OP_plus_uconst
	.byte	0x0	# uleb128 0x0
	.byte	0x3	# uleb128 0x3; (DIE (0x96) DW_TAG_member)
	.ascii "d\0"	# DW_AT_name
	.byte	0x1	# DW_AT_decl_file
	.byte	0x6	# DW_AT_decl_line
	.long	0x7b	# DW_AT_type
	.byte	0x2	# DW_AT_data_member_location
	.byte	0x23	# DW_OP_plus_uconst
	.byte	0x4	# uleb128 0x4
	.byte	0x0	# end of children of DIE 0x82

        ...

The two DW_TAG_structure_type members are distinguished only by their
DW_AT_decl_line attributes.  But those are optional --- a compiler can
omit them entirely.

So this patch has the correctness of the Dwarf 2 reader depending on
the presence of optional source location information for declarations.


> > Just in principle, this seems sloppy.  Dies are just arbitrary tree
> > nodes.  There's no reason to assume that if two parent nodes are
> > identical, we can skip the second one and all its children.
> It's not sloppy.
> Elimination at the top level is normal in other debuggers i know of that do 
> elimination.

I've no objection to the idea, just the implementation.