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

Paul Robinson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 15 09:52:09 PDT 2019


probinson added a comment.

In D68117#1709557 <https://reviews.llvm.org/D68117#1709557>, @SouraVX wrote:

> 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.


"open" here means the web page wasn't updated correctly. :-)  Yes, it was accepted and incorporated into DWARF 5, see http://dwarfstd.org/ShowIssue.php?issue=141215.3 (notes at the bottom).

> 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.

"It affects overload resolution" according to my record of the DWARF meeting where we discussed this.  Although "overload" resolution might not be the technically correct term.  Deleted is different from omitted, when trying to determine what to do with a particular source-language expression.

> 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.

I don't see any problem with omitting the attribute instead of explicitly saying DEFAULTED_no.  There is no DW_DEFAULTED_yes, if we provide the attribute at all it would have to distinguish in-class vs out-of-class in order to conform.  I know the compiler does treat them a little differently depending on in-class vs out-of-class; if nothing else, in-class is inlined more aggressively and might not have an out-of-line instance at all.  This might matter to a debugger trying to support source-language expression evaluation.


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

https://reviews.llvm.org/D68117





More information about the llvm-commits mailing list