Description
#45225 implemented a number of space optimizations. However, the DWARF was not updated to follow.
For example, for a sample type mentioned in the PR:
enum E { A(bool), B, C, D }
Nightly emits this DWARF:
<2><b9>: Abbrev Number: 6 (DW_TAG_union_type)
<ba> DW_AT_name : (indirect string, offset: 0x8a275): E
<be> DW_AT_byte_size : 1
<bf> DW_AT_alignment : 1
<3><c0>: Abbrev Number: 7 (DW_TAG_member)
<c1> DW_AT_name : (indirect string, offset: 0x7d): RUST$ENCODED$ENUM$0$B
<c5> DW_AT_type : <0xcc>
<c9> DW_AT_alignment : 1
<ca> DW_AT_data_member_location: 0
<3><cb>: Abbrev Number: 0
<2><cc>: Abbrev Number: 8 (DW_TAG_structure_type)
<cd> DW_AT_name : (indirect string, offset: 0x7092a): A
<d1> DW_AT_byte_size : 1
<d2> DW_AT_alignment : 1
<3><d3>: Abbrev Number: 7 (DW_TAG_member)
<d4> DW_AT_name : (indirect string, offset: 0x93): __0
<d8> DW_AT_type : <0xe0>
<dc> DW_AT_alignment : 1
<dd> DW_AT_data_member_location: 0
This is entirely missing entries for C and D (B is implicit in the special RUST$ENCODED$ENUM$0$B member name).
This is a good opportunity to remove RUST$ENCODED$ENUM and also RUST$ENUM$DISR.
@eddyb pointed out one approach on irc, namely to use the existing DW_TAG_variant_part support in DWARF. This will yield somewhat weird-looking output; first because the tag is only defined as a child of a structure, so the union will have to be wrapped in an artificial struct; and second because the discriminant is defined to be a reference to one of the struct's members.
This does seem likely to work, though; and since neither gdb nor lldb currently handle DW_TAG_variant_part at all, we probably have some leeway to do what we like. Plan B might be something like introduce a small DWARF extension to represent the layout in a form closer to what rustc is actually doing.
Unfortunately LLVM's debuginfo builder also does not seem to have a notion of discriminated unions, so step 1 will have to be an LLVM patch.