[PATCH] D42082: Add DWARF for discriminated unions

[Tom Tromey via llvm-commits]

>>>>> "David" == David Blaikie <dblaikie at gmail.com> writes:

David> Any difficulty with modelling this more generally - having a
David> DW_TAG_enum_type (DICompositeType) with a member that's a
David> DW_TAG_variant_part (probably another DICompositeType?) with the
David> members - so it doesn't matter whether there's a discriminator on
David> the enum_type, but there can be when needed.

I think this would be fine.

David> Fair point - if a debugger would benefit from/need this
David> information/distinction (ie: encoding the invariant union/enum
David> thing needs special handling in the debugger) rather than adding
David> an extra attribute to a DW_TAG_struct_type (and encoding the
David> invariant union/enum thing as just a straight struct_tag without
David> any variant_part/etc) then I think having a variant_part without
David> a discriminator, etc, is probably a good idea.

I'm afraid I didn't understand this.  Would you mind spelling it out a
bit more?  Maybe saying what you think the DIEs should look like or what
the API should look like would help me understand.


Here's a way that this could be made more flexible.

* Add DIBuilder::createVariantPartMember, to make a variant part.  This could
  be attached to whatever we think is reasonable -- an enum, a struct, etc.

* Also add DIBuilder::createVariantMember, which makes a single variant
  for a variant part.

Then, when emitting the variant part, if there is a non-variant member,
it is taken as the discriminant.  This ways Rust could emit a univariant
enum by simply omitting the discriminant.

This approach would let callers have more control over the construction
of the variant part, variants, and the placement thereof.


On the topic of where the variant part belongs -- it does not matter
much to me.  One reason this doesn't matter is that neither gdb nor lldb
deal with any of this at all; so whatever is done will require debugger
work.

Now, I've already written the gdb support based on the patches I
submitted.  However, it's fine to change that.  lldb on the other hand
will have to wait until I finish the lldb Rust plugin.

Furthermore, I think it's not very worthwhile to speculate about how
other tools might fail.  There isn't enough information.  But if this is
truly a concern then I would argue again for new tags everywhere,
because that's probably safest -- it's normal in DWARF to ignore what
one does not understand.


Let me know what you'd like.  What I would most like is a clear
direction forward.  Thanks.

Tom