Issue 141003.1: Need to mark ctors and dtors with =default
Section 5.7.7, pg 110
Compare these two ways of declaring a destructor:
struct S {
~S() {}
};
struct T {
~T() = default;
};
DWARF currently provides no way to distinguish these, but in the
Itanium C++ ABI, there is a difference, and the debugger needs to
know. In the first case, with a user-defined destructor, S is not
a trivial class, and the calling convention for a function that
returns S requires the caller to pass the address of a buffer for
the return value as an implicit first parameter. In the second
case, with a default destructor, T is trivial, and the calling
convention allows it to return the value on the stack.
Similarly, it may be necessary for a consumer to know if a
special member function has been explicitly deleted.
In order to represent deleted and default special member
functions, we should add a DW_AT_provided attribute with the
following values:
DW_PROV_declared
DW_PROV_implicit_default
DW_PROV_explicit_default
DW_PROV_explicit_delete
The rules in the C++ standard for determining whether a class is
trivial can depend on more details of the class than a consumer
can gather from the DWARF information, and may vary from one
version of the standard to the next. In order to give the
consumer an explicit indication of whether a class is trivial, we
should add a DW_AT_layout attribute with one of the following
values:
DW_LAYOUT_unspecified
DW_LAYOUT_non_trivial
DW_LAYOUT_trivial
DW_LAYOUT_pod
If the layout is unspecified, the consumer may attempt to
deduce it based on the knowledge it has of the class structure
and of the target ABI.
To allow the producer to represent these attributes with as
little additional space as possible, we should also add a new
FORM code, DW_FORM_const_present, that encodes a constant
value directly in the abbreviation declaration.
Changes to the spec:
Add the following rows to Table 2.2 ("Attribute names"):
Attribute Identifies or Specifies
--------- -----------------------
DW_AT_layout Class layout
DW_AT_provided How a special member function is
provided in the source code
Add the following non-normative paragraph to Section 5.7
("Structure, Union, Class and Interface Type Entries"):
C++ has the notion of a "trivial" class, whose objects can be
bitwise copied, and a "POD" ("Plain Old Data") struct or
class, representing a structure that can be shared with code
written in other languages. Trivial or POD classes may have
different rules for passing objects of that type as
parameters or return values.
Add the following paragraph to Section 5.7.1 ("Structure, Union
and Class Type Entries"):
A structure type, union type or class type entry may have a
DW_AT_layout attribute, whose value indicates whether it is a
non-trivial, trivial, or POD type. If not present, the layout
is assumed to be unspecified. <non-normative>If unspecified,
a consumer may be able to deduce the layout based on its
knowledge of the type and the ABI.</non-normative>
Add the following paragraph to Section 5.7.7 ("Member Function
Entries"):
If the member function entry describes a special member
function then that entry may have a DW_AT_provided attribute
whose value is one of the following:
* DW_PROV_declared (assumed if no DW_AT_provided attribute is
present) identifies a special member function that is
declared normally in the source code, whether or not there is
an explicit definition.
* DW_PROV_implicit_default identifies a special member
function that is not declared in the class, but was provided
as a default implementation by the compiler.
* DW_PROV_explicit_default identifies a special member
function that is declared in the class with "= default".
* DW_PROV_explicit_delete identifies a special member
function that is declared in the class with "= delete".
In Section 7.5.3 ("Abbreviations Tables"), add the following
paragraph immediately following the paragraph beginning "Finally,
the child encoding is followed by a series of attribute
specifications":
The attribute form DW_FORM_const_present is a special case.
For attributes with this form, the attribute specification
contains a third part, which is a signed LEB128 number. The
value of this number is used as the value of the attribute,
and no value is stored in the .debug_info section.
In Section 7.5.4 ("Attribute Encodings"), for class "constant",
change "seven forms" to "eight forms", and add to the end of the
paragraph:
There is also a implicit constant (DW_FORM_const_present),
whose value is provided as part of the abbreviation
declaration.
Add the following rows to Table 7.5 ("Attribute encodings"):
Attribute name Value Classes
-------------- ----- -------
DW_AT_layout xxx constant
DW_AT_provided xxx constant
Add the following row to Table 7.6 ("Attribute form encodings"):
Form name Value Classes
--------- ----- -------
DW_FORM_const_present xxx constant
Add the following sections to Chapter 7 ("Data Representation"):
7.X Class Layout Codes
The encodings of the constants used in the DW_AT_layout
attribute are given in Table 7.XX.
Table 7.XX Class layout encodings
Layout code name Value
---------------- -----
DW_LAYOUT_unspecified 0x00
DW_LAYOUT_non_trivial 0x01
DW_LAYOUT_trivial 0x02
DW_LAYOUT_pod 0x03
7.Y Special Member Function Codes
The encodings of the constants used in the DW_AT_provided
attribute are given in Table 7.YY.
Table 7.XX Special member function encodings
Special member function code name Value
--------------------------------- -----
DW_PROV_declared 0x00
DW_PROV_implicit_default 0x01
DW_PROV_explicit_default 0x02
DW_PROV_explicit_delete 0x03
In Appendix A, Table A.1 ("Attributes by tag value"), add
DW_AT_layout to DW_TAG_class_type, DW_TAG_struct_type, and
DW_TAG_union_type. Add DW_AT_provided to DW_TAG_subprogram.
--
Revised - 11/14/2014
Withdrawn -- 12/16/2014