dblaikie added a comment. 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? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68117/new/ https://reviews.llvm.org/D68117 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
