[PATCH] D68117: [DWARF-5] Support for C++11 defaulted, deleted member functions.

Tue Oct 15 07:49:05 PDT 2019

SouraVX added a comment.

In D68117#1708115 <https://reviews.llvm.org/D68117#1708115>, @dblaikie wrote:

> In D68117#1708114 <https://reviews.llvm.org/D68117#1708114>, @SouraVX wrote:
>
> > In D68117#1707680 <https://reviews.llvm.org/D68117#1707680>, @dblaikie wrote:
> >
> > > In D68117#1707578 <https://reviews.llvm.org/D68117#1707578>, @SouraVX wrote:
> > >
> > > > In D68117#1702595 <https://reviews.llvm.org/D68117#1702595>, @probinson wrote:
> > > >
> > > > > We really do want to pack the four mutually exclusive cases into two bits.  I have tried to give more explicit comments inline to explain how you would do this.  It really should work fine, recognizing that the "not defaulted" case is not explicitly represented in the textual IR because it uses a zero value in the defaulted/deleted subfield of SPFlags.
> > > >
> > > >
> > > > Thanks Paul, for suggesting this. Your approach works fine. But as I was working on some lvm-dwarfdump test cases. We seems to miss one corner case --
> > > >  Consider this test case;
> > > >  class foo{
> > > >
> > > >   foo() = default;
> > > >   ~foo() = default;
> > > >    void not_special() {}
> > > >
> > > > };
> > > >  void not_a_member_of_foo(){}
> > > >
> > > > Now I'm getting DW_AT_defaulted getting emitted with value DW_DEFAULTED_no, for functions "not_special" and "not_a_member_of_foo". This behavior is undesirable since, DW_AT_defaulted attributes is only valid for C++ special member functions{Constructors/Destructors, ...}.
> > > >
> > > > Please correct me if I'm wrong -- Now This attributes to- implicitly defined "0" NotDefaulted bit.  which is getting checked{that's fine as long as we have a dedicated bits for distinguishing} and true for every subprogram or function in a CU.
> > > >  void DwarfUnit::applySubprogramAttributes( ...
> > > >  ...
> > > >  else if (SP->isNotDefaulted())
> > > >
> > > >   addUInt(SPDie, dwarf::DW_AT_defaulted, dwarf::DW_FORM_data1,
> > > >           dwarf::DW_DEFAULTED_no);
> > > >
> > > > ...
> > >
> > >
> > > Perhaps we should only emit DEFAULTED_yes, and assume anything that's not DEFAULTED_yes, is... not defaulted?
> > >
> > > Also: What features is anyone planning to build with this information? I'm sort of inclined not to implement features without some use-case in mind/planned.
> >
> >
> > Hi David, thanks for your suggestion. But, if we do that way, we may not be able to capture it's location and, whether that function was defaulted in or out of class.
>
>
> Not sure I follow - for an out-of-class defaulting, I'd expect the non-defining (declaration) DW_TAG_subprogram inside the class to not have the DW_AT_defaulted attribute - and then the out of line definition would have DW_AT_defaulted = DEFAULTED_yes. For an inline defaulted definition, the non-defining DW_TAG_subprogram would have DW_AT_defaulted= DEFAULTED_yes, and the defining DW_TAG_subprogram would have no DW_AT_defaulted, it would inherit it from the declaration via DW_AT_specification.
>
> > Regarding the intent behind doing this, we have an initial internal requirement for 100% compliance towards DWARF-5 from producer{Clang} side.
>
> I'd like to discuss that requirement a bit further - obviously I'm not your management/customers/etc, so I may not be able to sway you, but I don't believe absence of DW_AT_defaulted would classify as DWARFv5 non-conformance to me.
>
> Producing, say, debug_ranges instead of debug_rnglists (both in terms of teh section used, and the format of the bytes in that section) would be non-conformant. But DWARF only suggests what some forms/attributes/etc might be useful for, it doesn't require them by any means.
>
> Any idea what the particular motivation for compliance is? So you/we could evaluate whether this feature is meeting a need or not?

Hi David, 
I did some digging about DW_AT_defaulted and stuff, not much of a success but. Here's what I found -- http://dwarfstd.org/Issues.php?type=closed4  -- here it;s still marked as open, not sure what that means. Abbreviations on this page doesn't describe what "open" meant. But since, it's already in DWARF5 Spec -- it must be accepted.

Their's not much information available behind the suggestion or intention for adding this feature to Spec. http://dwarfstd.org/ShowIssue.php?issue=141215.3  -- I think Paul can better provide remarks on this one.

GCC and GDB side of things-- I've checked GCC-9.2.0 implements this feature, but didn't noticed any use of this feature from GDB side{GDB.8.3}. It's merely declaration of the forms available. GCC's implementation  doesn't emit DW_DEFAULTED_no -- skipping DW_AT_defaulted attribute for that function. Current  GCC implementation addresses in_class, out_of_class attributes and of_course DW_AT_deleted.

Regarding my patch and whether we should add this in clang/llvm--
Please correct me, in case I'm mistaken. David are you suggesting that, may be just "DW_DEFAULTED_yes"  can suffice our needs instead of using the Spec {in_class, out_of_class, DEFAULTED_no}. We could do that, that would incur mostly adding a custom "DW_DEFAULTED_yes" {non-conflicting to Spec} opcode in LLVM, Not sure about this to addition to LLVM ??. 
Or we can choose same approach as GCC.
Please share your thoughts on this. which direction should we choose ?? Or you guys have altogether something different in mind.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68117/new/

https://reviews.llvm.org/D68117