<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 19, 2018 at 8:32 AM Tom Tromey <<a href="mailto:ttromey@mozilla.com">ttromey@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>>>>> "David" == David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> writes:<br>
<br>
David> Any difficulty with modelling this more generally - having a<br>
David> DW_TAG_enum_type (DICompositeType) with a member that's a<br>
David> DW_TAG_variant_part (probably another DICompositeType?) with the<br>
David> members - so it doesn't matter whether there's a discriminator on<br>
David> the enum_type, but there can be when needed.<br>
<br>
I think this would be fine.<br>
<br>
David> Fair point - if a debugger would benefit from/need this<br>
David> information/distinction (ie: encoding the invariant union/enum<br>
David> thing needs special handling in the debugger) rather than adding<br>
David> an extra attribute to a DW_TAG_struct_type (and encoding the<br>
David> invariant union/enum thing as just a straight struct_tag without<br>
David> any variant_part/etc) then I think having a variant_part without<br>
David> a discriminator, etc, is probably a good idea.<br>
<br>
I'm afraid I didn't understand this.  Would you mind spelling it out a<br>
bit more?  Maybe saying what you think the DIEs should look like or what<br>
the API should look like would help me understand.<br></blockquote><div><br>Sure, here's an attempt to be more clear *fingers crossed*<br><br>If this union-of-one-thing needs special handling in the debugger, such that (using C syntax for my convenience) "struct X { int i; };" and "union X { int i; };" can't be encoded the same, then it seems reasonable to me to encode the latter as:<br><br>  DW_TAG_struct<br>    DW_TAG_variant_part<br>      DW_TAG_variant<br><br>no DW_AT_discr, no DW_AT_discr_values, etc.<br><br>Though of course this is non-conforming, I suppose (specifically "If the variant part does not have a discriminant (tag field), the variant part entry has a DW_AT_type attribute to represent the tag type." - sounds like the variant_part above would need a DW_AT_type, but there is no tag type, arguably it could be a void tag type?)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here's a way that this could be made more flexible.<br>
<br>
* Add DIBuilder::createVariantPartMember, to make a variant part.  This could<br>
  be attached to whatever we think is reasonable -- an enum, a struct, etc.<br>
<br>
* Also add DIBuilder::createVariantMember, which makes a single variant<br>
  for a variant part.<br>
<br>
Then, when emitting the variant part, if there is a non-variant member,<br>
it is taken as the discriminant.  This ways Rust could emit a univariant<br>
enum by simply omitting the discriminant.<br>
<br>
This approach would let callers have more control over the construction<br>
of the variant part, variants, and the placement thereof.<br></blockquote><div><br>*nod* Roughly what I had in mind. Open to other opinions/if the review has already moved on from this area, etc.<br><br>I was thinking more, rather than distinguish the discriminant by being a non-variant member, sounded like/I thought you were proposing having the extra data for the variant_part store the pointer to that? But I've probably misremembered.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On the topic of where the variant part belongs -- it does not matter<br>
much to me.  One reason this doesn't matter is that neither gdb nor lldb<br>
deal with any of this at all; so whatever is done will require debugger<br>
work.<br>
<br>
Now, I've already written the gdb support based on the patches I<br>
submitted.  However, it's fine to change that.  lldb on the other hand<br>
will have to wait until I finish the lldb Rust plugin.<br>
<br>
Furthermore, I think it's not very worthwhile to speculate about how<br>
other tools might fail.  There isn't enough information.  But if this is<br>
truly a concern then I would argue again for new tags everywhere,<br>
because that's probably safest -- it's normal in DWARF to ignore what<br>
one does not understand.<br>
<br>
<br>
Let me know what you'd like.  What I would most like is a clear<br>
direction forward.  Thanks.<br>
<br>
Tom<br>
</blockquote></div></div>