DWARF Standard

Section 5.7.10, pg 123

Hello,

Starting at line 5, section 5.7.10 Variant Entries says:
> 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 constraint that the entry for the discriminant must be a variant part entry
child looks overly restrictive, at least for Ada: there can be several variant
parts which refer to a unique discriminant. For instance:

 1.  type Rec (I : Integer) is record
 2.     case I is
 3.        when Positive =>
 4.           C : Character;
 5.           case I is
 6.              when 0 =>
 7.                 null;
 8.              when others =>
 9.                 N : Natural;
10.           end case;
11.        when others =>
12.           S : String (1 .. 10);
13.     end case;
14.  end record;

Here, the Rec structure has two nested variant parts: one lines 2-13 and one
lines 5-10, and both have the same discriminant: the member I (line 1). Both
variant parts must be described in DWARF as DW_TAG_variant_part entries, but
following the above rule, one would have to materialize the I discriminant
with two DW_TAG_member entries: one for each variant part, so that each is
truly the *child* of each variant part entry.

Having two homonym DW_TAG_member entries inside a single structure entry looks
quite unfriendly for DWARF consumers, and also a waste of space. It would seem
more natural, at least for Ada, to be able to put the DW_TAG_member entry for I
directly under the DW_TAG_structure one that describes the Rec structure. In
the Ada source, the declaration of I is indeed outside of all variant parts,
and this would allow to have only one DW_AT_member entry referenced by the two
variant part entries.

Would it be possible to relax the above rule? For instance saying:
> If the variant part has a discriminant, the discriminant is represented by a
> separate debugging information entry which is a direct child, a sibling or a
> parent of the variant part entry.

For the record, this issue was discussed on:

* the dwarf-discuss@ mailing list in 2006
  <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2006-August/001710.html>

* a patch review for LLVM a week ago <https://reviews.llvm.org/D42082>

* GCC's bug tracker shortly after
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935>