[Dwarf-discuss] Encoding variant records: request for clarification.

Todd Allen todd.allen
Mon Aug 21 20:16:49 GMT 2006


> Paul Hilfinger wrote:
> > Evidently, I did not make the source of my confusion sufficiently clear.
> > Again, the type in question is
> > 
> >      type R (N : Integer) is record
> >         Data : String (1 .. N);
> >         case N is
> >         when 0 =>
> >             Name : String (1 .. N);
> >         when 1..20 =>
> >             Id, Port : Integer;
> >         when others =>
> >             null;
> >         end case;
> >      end record;

> Paul Hilfinger wrote:
> >     If the variant part has a discriminant, the discriminant is represented
> >     by a separate debugging information entry which is a ->>CHILD OF THE 
> >     VARIANT PART ENTRY.<<- ... The variant part entry will have a 
> >     DW_AT_discr attribute whose value is a reference to the member entry
> >     for the discriminant.
> > 
> > So field N would be a child of the variant_part representing 
> > 
> >    case N is ... end case
> > 
> > But N is ALREADY a child of the structure_type (or whatever) that represents
> > 
> >     type R (N: Integer) is record ... end record;
> > 
> > So what gives?

On Sat, Aug 19, 2006 at 10:59:35AM -0400, Ron Brender wrote:
> Paul,
> 
> Ahhh, now I understand the question. And it is a good one at that!
> It appears that Section 5.6.9 in Version 3 survives unchanged from 
> Version 2 (where the Section number was different). I don't recall any 
> discussion of this particular matter during V3 development.
> 
> My take is
> 
> 1) It is perfectly reasonable for the DW_TAG_variant_part in this 
> example to not have any member child (just the DW_TAG_variant children).
> 
> 2) The DW_AT_discr attribute of the DW_TAG_variant_part entry should 
> refer to the earlier member entry for N as usual.
> 
> The wording in S5.6.9 does not obviously allow this, although it does 
> allow no member child for a tagless variant (a Pascal thing, yes?). The 
> text should be revised to clarify this. Further your example would be a 
> good addition in D.2.2.
> 

I agree with Ron.  We at Concurrent chose to disregard that clause from
5.6.9.  Whether intentionally or not, I can't remember.  It was 12 years ago.
:)  I suppose the standard's logic might have been that the discriminant
member should exist inside the variant part and not outside of it.  But that
doesn't scale very well to records with multiple nested variant parts, each
of which could use the same discriminant.  And that may have been why we
disregarded it.

For the above snippet, our compiler generates a description akin to the
following.  Although I've ripped out all Concurrent-specific artificial
members, and most Concurrrent-specific attributes, and redirected a couple
upper bound references to non-artificial members.  This should reduce this to
just the pertintent bits.  Oh, and in this representation, a DW_TAG_padding
is a "DIE" with a 0 abbrev which terminates a level of the hierarchy.

   DIE (0x3)
      DW_TAG_structure_type
      DW_AT_name(DW_FORM_string) "r"

      DIE (0x4)
         DW_TAG_member
         DW_AT_type(DW_FORM_ref_addr) [A$dw_integer]
         DW_AT_data_member_location(DW_FORM_block) [...]
         DW_AT_discriminant(DW_FORM_flag) TRUE
         DW_AT_name(DW_FORM_string) "n"

      DIE (0x6)
         DW_TAG_array_type
         DW_AT_subtype_parent(DW_FORM_ref_addr) [A$dw_string]

         DIE (0x7)
            DW_TAG_subrange_type
            DW_AT_type(DW_FORM_ref_addr) [A$dw_integer]
            DW_AT_lower_bound(DW_FORM_sdata) 1
            DW_AT_upper_bound(DW_FORM_ref_addr) 0x4

      DIE (0x9)
         DW_TAG_padding

      DIE (0xa)
         DW_TAG_member
         DW_AT_type(DW_FORM_ref_addr) 0x6
         DW_AT_data_member_location(DW_FORM_block) [...]
         DW_AT_name(DW_FORM_string) "data"

      DIE (0xe)
         DW_TAG_variant_part
         DW_AT_discr(DW_FORM_ref_addr) 0x4

         DIE (0xf)
            DW_TAG_variant
            DW_AT_discr_value(DW_FORM_sdata) 0

            DIE (0x10)
               DW_TAG_array_type
               DW_AT_subtype_parent(DW_FORM_ref_addr) [A$dw_string]

               DIE (0x11)
                  DW_TAG_subrange_type
                  DW_AT_type(DW_FORM_ref_addr) [A$dw_integer]
                  DW_AT_lower_bound(DW_FORM_sdata) 1
                  DW_AT_upper_bound(DW_FORM_ref_addr) 0x4

            DIE (0x13)
               DW_TAG_padding

            DIE (0x14)
               DW_TAG_member
               DW_AT_type(DW_FORM_ref_addr) 0x10
               DW_AT_data_member_location(DW_FORM_block) [...]
               DW_AT_name(DW_FORM_string) "name"

         DIE (0x18)
            DW_TAG_padding

         DIE (0x19)
            DW_TAG_variant
            DW_AT_discr_list(DW_FORM_block) [1..20]

            DIE (0x1a)
               DW_TAG_member
               DW_AT_type(DW_FORM_ref_addr) [A$dw_integer]
               DW_AT_data_member_location(DW_FORM_block) [...]
               DW_AT_name(DW_FORM_string) "id"

            DIE (0x1c)
               DW_TAG_member
               DW_AT_type(DW_FORM_ref_addr) [A$dw_integer]
               DW_AT_data_member_location(DW_FORM_block) [...]
               DW_AT_name(DW_FORM_string) "port"

         DIE (0x1e)
            DW_TAG_padding

         DIE (0x1f)
            DW_TAG_variant

      DIE (0x21)
         DW_TAG_padding

-- 
Todd Allen
Concurrent Computer Corporation





More information about the Dwarf-discuss mailing list