Bring up to date with the February 2015 meeting and the

[dwarf-doc.git] / dwarf5 / latexdoc / typeentries.tex

\chapter{Type Entries}
\label{chap:typeentries}
This section presents the debugging information entries
that describe program types: base types, modified types and
user\dash defined types.

If the scope of the declaration of a named type begins after
\hypertarget{chap:DWATstartscopetypedeclaration}{}
the low pc value for the scope most closely enclosing the
declaration, the declaration may have a 
\DWATstartscope{}
attribute as described for objects in 
Section \refersec{chap:dataobjectentries}.

\section{Base Type Entries}
\label{chap:basetypeentries}

\textit{A base type is a data type that is not defined in terms of
other data types. 
\addtoindexx{fundamental type|see{base type entry}}
Each programming language has a set of base
types that are considered to be built into that language.}

A base type is represented by a debugging information entry
with the tag 
\DWTAGbasetypeTARG.

A \addtoindex{base type entry}
has a \DWATname{} attribute
whose
\addtoindexx{name attribute}
value is
a null\dash terminated string containing the name of the base type
as recognized by the programming language of the compilation
unit containing the base type entry.

A base type entry has 
\addtoindexx{encoding attribute}
a \DWATencoding{} attribute describing
how the base type is encoded and is to be interpreted. The
value of this attribute is an 
\livelink{chap:classconstant}{integer constant}. The set of
values and their meanings for the
\DWATencoding{} attribute
is given in 
Table \refersec{tab:encodingattributevalues}
and following text.  

A base type entry
may have a \DWATendianity{} attribute
\addtoindexx{endianity attribute}
as described in 
Section \refersec{chap:dataobjectentries}. 
If omitted, the encoding assumes the representation that
is the default for the target architecture.

A base type entry has 
\hypertarget{chap:DWATbytesizedataobjectordatatypesize}{}
either a \DWATbytesize{} attribute
\hypertarget{chap:DWATbitsizebasetypebitsize}{}
or a \DWATbitsize{} attribute 
\addtoindexx{bit size attribute}
whose \livelink{chap:classconstant}{integer constant} value
(see Section \refersec{chap:byteandbitsizes}) 
is the amount of storage needed to hold
a value of the type.

\needlines{5}
\textit{For example, the 
\addtoindex{C} type \texttt{int} on a machine that uses 32\dash bit
integers is represented by a base type entry with a name
attribute whose value is \doublequote{int}, an encoding attribute
whose value is \DWATEsigned{}
and a byte size attribute whose value is 4.}

If the value of an object of the given type does not fully
occupy the storage described by a byte size attribute,
\hypertarget{chap:DWATdatabitoffsetbasetypebitlocation}{}
the base type entry may also have 
\addtoindexx{bit size attribute}
a 
\DWATbitsize{} and a
\DWATdatabitoffset{} attribute, 
both 
\addtoindexx{data bit offset attribute}
of whose values are
\livelink{chap:classconstant}{integer constant} values
(see Section \refersec{chap:staticanddynamicvaluesofattributes}). 
The bit size
attribute describes the actual size in bits used to represent
values of the given type. The data bit offset attribute is the
offset in bits from the beginning of the containing storage to
the beginning of the value. Bits that are part of the offset
are padding. The data bit offset uses the bit numbering and
direction conventions that are appropriate to the current
language on the
target system to locate the beginning of the storage and
value. If this attribute is omitted a default data bit offset
of zero is assumed.

\textit{Attribute 
\DWATdatabitoffset{} 
is 
\addtoindexx{bit offset attribute (Version 3)}
\addtoindexx{bit offset attribute (Version 3)|see{\textit{also} data bit offset attribute}}
new 
\addtoindexx{data bit offset attribute}
in 
\addtoindex{DWARF Version 4}, unchanged in \addtoindex{DWARF Version 5}, and
is also used for bit field members 
(see Section \refersec{chap:datamemberentries}). 
It
\hypertarget{chap:DWATbitoffsetbasetypebitlocation}{}
replaces the attribute 
\DWATbitoffset{} 
when used for base
\addtoindexx{bit offset attribute (Version 3)}
types as defined in \DWARFVersionIII{} and earlier.
\DWATbitoffset{}
is deprecated for use in base types in DWARF Version 4 and later.
See Section 5.1 in the \DWARFVersionIV{}
specification for a discussion of compatibility considerations.}

\begin{table}[!here]
\caption{Encoding attribute values}
\label{tab:encodingattributevalues}
\centering
\begin{tabular}{l|p{8cm}}
\hline
Name&Meaning\\ \hline
\DWATEaddressTARG{} & linear machine address (for segmented\break
  addresses see
  Section \refersec{chap:segmentedaddresses}) \\
\DWATEbooleanTARG& true or false \\

\DWATEcomplexfloatTARG& complex binary
floating\dash point number \\
\DWATEfloatTARG{} & binary floating\dash point number \\
\DWATEimaginaryfloatTARG& imaginary binary
floating\dash point number \\
\DWATEsignedTARG& signed binary integer \\
\DWATEsignedcharTARG& signed character \\
\DWATEunsignedTARG{} & unsigned binary integer \\
\DWATEunsignedcharTARG{} & unsigned character \\
\DWATEpackeddecimalTARG{}  & packed decimal \\
\DWATEnumericstringTARG& numeric string \\
\DWATEeditedTARG{} & edited string \\
\DWATEsignedfixedTARG{} & signed fixed\dash point scaled integer \\
\DWATEunsignedfixedTARG& unsigned fixed\dash point scaled integer \\
\DWATEdecimalfloatTARG{} & decimal floating\dash point number \\ 
\DWATEUTFTARG{} & \addtoindexi{Unicode character}{Unicode character base type} \\
\DWATEASCIITARG{} & \addtoindexi{ASCII character}{ASCII character base type}\\
\DWATEUCSTARG{} & \addtoindexi{ISO 10646 character}{ISO 10646 character base type}
                  \addtoindexx{ISO 10646 character set standard}  \\
\hline
\end{tabular}
\end{table}

\textit{The \DWATEdecimalfloat{} encoding is intended for
floating\dash point representations that have a power\dash of\dash ten
exponent, such as that specified in IEEE 754R.}

\textit{The \DWATEUTF{} encoding is intended for \addtoindex{Unicode}
string encodings (see the Universal Character Set standard,
ISO/IEC 10646\dash 1:1993).
 \addtoindexx{ISO 10646 character set standard}
For example, the 
\addtoindex{C++} type char16\_t is
represented by a base type entry with a name attribute whose
value is \doublequote{char16\_t}, an encoding attribute whose value
is \DWATEUTF{} and a byte size attribute whose value is 2.}

\textit{The \DWATEASCII{} and \DWATEUCS{} encodings are intended for
the {Fortran 2003} string kinds 
\texttt{ASCII}\index{ASCII@\texttt{ASCII} (Fortran string kind)} (ISO/IEC 646:1991) and
\texttt{ISO\_10646}\index{ISO\_10646@\texttt{ISO\_10646} (Fortran string kind)} (UCS-4 in ISO/IEC 10646:2000).}
\addtoindexx{ISO 10646 character set standard}

The 
\DWATEpackeddecimal{} 
and 
\DWATEnumericstring{} 
base types
represent packed and unpacked decimal string numeric data
types, respectively, either of which may be 
either 
\addtoindexx{decimal scale attribute}
signed
\addtoindexx{decimal sign attribute}
or 
\addtoindexx{digit count attribute}
unsigned. 
\hypertarget{chap:DWATdecimalsigndecimalsignrepresentation}{}
These 
\hypertarget{chap:DWATdigitcountdigitcountforpackeddecimalornumericstringtype}{}
base types are used in combination with
\DWATdecimalsign, 
\DWATdigitcount{} and 
\DWATdecimalscale{}
attributes.

\needlines{5}
A \DWATdecimalsign{} attribute 
\addtoindexx{decimal sign attribute}
is an \livelink{chap:classconstant}{integer constant} that
conveys the representation of the sign of the decimal type
(see Table \refersec{tab:decimalsignattributevalues}). 
Its \livelink{chap:classconstant}{integer constant} value is interpreted to
mean that the type has a leading overpunch, trailing overpunch,
leading separate or trailing separate sign representation or,
alternatively, no sign at all.

\begin{table}[here]
\caption{Decimal sign attribute values}
\label{tab:decimalsignattributevalues}
\centering
\begin{tabular}{l|p{9cm}}
\hline
 Name & Meaning \\
\hline
\DWDSunsignedTARG{} &  Unsigned \\
\DWDSleadingoverpunchTARG{} & Sign
is encoded in the most significant digit in a target\dash dependent  manner \\
\DWDStrailingoverpunchTARG{} & Sign
is encoded in the least significant digit in a target\dash dependent manner \\
\DWDSleadingseparateTARG{} 
& Decimal type: Sign is a \doublequote{+} or \doublequote{-} character 
to the left of the most significant digit. \\
\DWDStrailingseparateTARG{} 
& Decimal type: Sign is a \doublequote{+} or \doublequote{-} character 
to the right of the least significant digit. \\
&Packed decimal type: Least significant nibble contains
a target\dash dependent value
indicating positive or negative. \\
\hline
\end{tabular}
\end{table}

\hypertarget{chap:DWATdecimalscaledecimalscalefactor}{}
The \DWATdecimalscale{}
attribute 
\addtoindexx{decimal scale attribute}
is an integer constant value
that represents the exponent of the base ten scale factor to
be applied to an instance of the type. A scale of zero puts the
decimal point immediately to the right of the least significant
digit. Positive scale moves the decimal point to the right
and implies that additional zero digits on the right are not
stored in an instance of the type. Negative scale moves the
decimal point to the left; if the absolute value of the scale
is larger than the digit count, this implies additional zero
digits on the left are not stored in an instance of the type.

The 
\DWATdigitcount{}
attribute 
\addtoindexx{digit count attribute}
is an \livelink{chap:classconstant}{integer constant}
value that represents the number of digits in an instance of
the type.

The \DWATEedited{}
base 
\hypertarget{chap:DWATpicturestringpicturestringfornumericstringtype}{}
type is used to represent an edited
numeric or alphanumeric data type. It is used in combination
with a \DWATpicturestring{} attribute whose value is a 
null\dash terminated string containing the target\dash dependent picture
string associated with the type.

If the edited base type entry describes an edited numeric
data type, the edited type entry has a \DWATdigitcount{} and a
\DWATdecimalscale{} attribute. 
\addtoindexx{decimal scale attribute}
These attributes have the same
interpretation as described for the 
\DWATEpackeddecimal{} and
\DWATEnumericstring{} base 
types. If the edited type entry
describes an edited alphanumeric data type, the edited type
entry does not have these attributes.


\textit{The presence or absence of the \DWATdigitcount{} and
\DWATdecimalscale{} attributes 
\addtoindexx{decimal scale attribute}
allows a debugger to easily
distinguish edited numeric from edited alphanumeric, although
in principle the digit count and scale are derivable by
interpreting the picture string.}

The \DWATEsignedfixed{} and \DWATEunsignedfixed{} entries
describe signed and unsigned fixed\dash point binary data types,
respectively.

The fixed binary type entries have 
\addtoindexx{digit count attribute}
a 
\DWATdigitcount{}
attribute with the same interpretation as described for the
\DWATEpackeddecimal{} and \DWATEnumericstring{} base types.

\needlines{4}
For a data type with a decimal scale factor, the fixed binary
type entry has a 
\DWATdecimalscale{} attribute 
\addtoindexx{decimal scale attribute}
with the same
interpretation as described for the 
\DWATEpackeddecimal{}
and \DWATEnumericstring{} base types.

\hypertarget{chap:DWATbinaryscalebinaryscalefactorforfixedpointtype}{}
For a data type with a binary scale factor, the fixed
\addtoindexx{binary scale attribute}
binary type entry has a 
\DWATbinaryscale{} attribute. 
The
\DWATbinaryscale{} attribute 
is an \livelink{chap:classconstant}{integer constant} value
that represents the exponent of the base two scale factor to
be applied to an instance of the type.  Zero scale puts the
binary point immediately to the right of the least significant
bit. Positive scale moves the binary point to the right and
implies that additional zero bits on the right are not stored
in an instance of the type. Negative scale moves the binary
point to the left; if the absolute value of the scale is
larger than the number of bits, this implies additional zero
bits on the left are not stored in an instance of the type.

For 
\hypertarget{chap:DWATsmallscalefactorforfixedpointtype}{}
a data type with a non\dash decimal and non\dash binary scale factor,
the fixed binary type entry has a 
\DWATsmall{} attribute which
\addtoindexx{small attribute}
references a 
\DWTAGconstant{} entry. The scale factor value
is interpreted in accordance with the value defined by the
\DWTAGconstant{} entry. The value represented is the product
of the integer value in memory and the associated constant
entry for the type.

\textit{The \DWATsmall{} attribute 
is defined with the \addtoindex{Ada} \texttt{small}
attribute in mind.}

\section{Unspecified Type Entries}
\label{chap:unspecifiedtypeentries}
\addtoindexx{unspecified type entry}
\addtoindexx{void type|see{unspecified type entry}}
Some languages have constructs in which a type 
may be left unspecified or the absence of a type
may be explicitly indicated.

An unspecified (implicit, unknown, ambiguous or nonexistent)
type is represented by a debugging information entry with
the tag \DWTAGunspecifiedtypeTARG. 
If a name has been given
to the type, then the corresponding unspecified type entry
has a \DWATname{} attribute 
\addtoindexx{name attribute}
whose value is
a null\dash terminated
string containing the name as it appears in the source program.

The interpretation of this debugging information entry is
intentionally left flexible to allow it to be interpreted
appropriately in different languages. For example, in 
\addtoindex{C} and \addtoindex{C++}
the language implementation can provide an unspecified type
entry with the name \doublequote{void} which can be referenced by the
type attribute of pointer types and typedef declarations for
'void' (see 
Sections \refersec{chap:typemodifierentries} and 
%The following reference was valid, so the following is probably correct.
Section \refersec{chap:typedefentries}, 
respectively). As another
example, in \addtoindex{Ada} such an unspecified type entry can be referred
to by the type attribute of an access type where the denoted
\addtoindexx{incomplete type (Ada)}
type is incomplete (the name is declared as a type but the
definition is deferred to a separate compilation unit).

\addtoindex{C++} permits using the 
\autoreturntype{} specifier for the return type of a member function declaration. 
The actual return type is deduced based on the definition of the 
function, so it may not be known when the function is declared.  The language 
implementation can provide an unspecified type entry with the name \texttt{auto} which 
can be referenced by the return type attribute of a function declaration entry.  
When the function is later defined, the \DWTAGsubprogram{} entry for the definition
includes a reference to the actual return type.


\section{Type Modifier Entries}
\label{chap:typemodifierentries}
\addtoindexx{type modifier entry}
\addtoindexx{type modifier|see{atomic type entry}}
\addtoindexx{type modifier|see{constant type entry}}
\addtoindexx{type modifier|see{reference type entry}}
\addtoindexx{type modifier|see{restricted type entry}}
\addtoindexx{type modifier|see{packed type entry}}
\addtoindexx{type modifier|see{pointer type entry}}
\addtoindexx{type modifier|see{shared type entry}}
\addtoindexx{type modifier|see{volatile type entry}}
A base or user\dash defined type may be modified in different ways
in different languages. A type modifier is represented in
DWARF by a debugging information entry with one of the tags
given in Table \refersec{tab:typemodifiertags}.

If a name has been given to the modified type in the source
program, then the corresponding modified type entry has
a \DWATname{} attribute 
\addtoindexx{name attribute}
whose value is a null\dash terminated
string containing the modified type name as it appears in
the source program.

Each of the type modifier entries has 
\addtoindexx{type attribute}
a 
\DWATtype{} attribute,
whose value is a \livelink{chap:classreference}{reference} 
to a debugging information entry
describing a base type, a user-defined type or another type
modifier.

A modified type entry describing a 
\addtoindexx{pointer type entry}
pointer or \addtoindex{reference type}
(using \DWTAGpointertype,
\DWTAGreferencetype{} or
\DWTAGrvaluereferencetype) 
% Another instance of no-good-place-to-put-index entry.
may
\addtoindexx{address class attribute} 
have 
\hypertarget{chap:DWATadressclasspointerorreferencetypes}{}
a 
\DWATaddressclass{}
attribute to describe how objects having the given pointer
or reference type ought to be dereferenced.

A modified type entry describing a \addtoindex{UPC} shared qualified type
(using \DWTAGsharedtype) may have a
\DWATcount{} attribute
\addtoindexx{count attribute}
whose value is a constant expressing the (explicit or implied) blocksize specified for the
type in the source. If no count attribute is present, then the \doublequote{infinite}
blocksize is assumed.

When multiple type modifiers are chained together to modify
a base or user-defined type, the tree ordering reflects the
semantics of the 
\addtoindexx{reference type entry, lvalue|see{reference type entry}}
applicable language 
\addtoindexx{reference type entry, rvalue|see{rvalue reference type entry}}
rather 
\addtoindexx{parameter|see{macro formal parameter list}}
than 
\addtoindexx{parameter|see{\textit{this} parameter}}
the 
\addtoindexx{parameter|see{variable parameter attribute}}
textual
\addtoindexx{parameter|see{optional parameter attribute}}
order 
\addtoindexx{parameter|see{unspecified parameters entry}}
in 
\addtoindexx{parameter|see{template value parameter entry}}
the 
\addtoindexx{parameter|see{template type parameter entry}}
source 
\addtoindexx{parameter|see{formal parameter entry}}
presentation.

\begin{table}[here]
\caption{Type modifier tags}
\label{tab:typemodifiertags}
\centering
\begin{tabular}{l|p{9cm}}
\hline
Name&Meaning\\ \hline
\DWTAGatomictypeTARG{} & C \addtoindex{\_Atomic} qualified type \\
\DWTAGconsttypeTARG{} &  C or C++ const qualified type
\addtoindexx{const qualified type entry} \addtoindexx{C} \addtoindexx{C++} \\
\DWTAGpackedtypeTARG& \addtoindex{Pascal} or Ada packed type\addtoindexx{packed type entry}
\addtoindexx{packed qualified type entry} \addtoindexx{Ada} \addtoindexx{Pascal} \\
\DWTAGpointertypeTARG{} & Pointer to an object of
the type being modified \addtoindexx{pointer qualified type entry} \\
\DWTAGreferencetypeTARG& \addtoindex{C++} (lvalue) reference 
to an object of the type 
\addtoindexx{reference type entry}
\mbox{being} modified
\addtoindexx{reference qualified type entry} \\
\DWTAGrestricttypeTARG& \addtoindex{C} 
restrict 
\addtoindexx{restricted type entry}
qualified type
\addtoindexx{restrict qualified type} \\
\DWTAGrvaluereferencetypeTARG{} & \addtoindex{C++}
\addtoindexx{rvalue reference type entry}
rvalue 
\addtoindexx{restricted type entry}
reference to an object of the type \mbox{being} modified 
\addtoindexx{rvalue reference qualified type entry} \\
\DWTAGsharedtypeTARG&\addtoindex{UPC} shared qualified type 
\addtoindexx{shared qualified type entry} \\
\DWTAGvolatiletypeTARG&\addtoindex{C} or \addtoindex{C++} volatile qualified type 
\addtoindexx{volatile qualified type entry} \\
\hline
\end{tabular}
\end{table}

\needlines{6}
\textit{As examples of how type modifiers are ordered, consider the following
\addtoindex{C} declarations:}
\begin{lstlisting}[numbers=none]
   const unsigned char * volatile p;
\end{lstlisting}
\textit{which represents a volatile pointer to a constant
character. This is encoded in DWARF as:}

\begin{dwflisting}
\begin{alltt}
        \DWTAGvariable(p) -->
            \DWTAGvolatiletype -->
                \DWTAGpointertype -->
                    \DWTAGconsttype -->
                        \DWTAGbasetype(unsigned char)
\end{alltt}
\end{dwflisting}

%\needlines{5}
\textit{On the other hand}
\begin{lstlisting}[numbers=none]                        
   volatile unsigned char * const restrict p;
\end{lstlisting}
\textit{represents a restricted constant
pointer to a volatile character. This is encoded as:}

\begin{dwflisting}
\begin{alltt}
        \DWTAGvariable(p) -->
            \DWTAGrestricttype -->
                \DWTAGconsttype -->
                    \DWTAGpointertype -->
                        \DWTAGvolatiletype -->
                            \DWTAGbasetype(unsigned char)
\end{alltt}
\end{dwflisting}

\section{Typedef Entries}
\label{chap:typedefentries}
A named type that is defined in terms of another type
definition is represented by a debugging information entry with
\addtoindexx{typedef entry}
the tag \DWTAGtypedefTARG. 
The typedef entry has a \DWATname{} attribute 
\addtoindexx{name attribute}
whose value is a null\dash terminated string containing
the name of the typedef as it appears in the source program.

The typedef entry may also contain 
\addtoindexx{type attribute}
a 
\DWATtype{} attribute whose
value is a \livelink{chap:classreference}{reference} 
to the type named by the typedef. If
the debugging information entry for a typedef represents
a declaration of the type that is not also a definition,
it does not contain a type attribute.

\textit{Depending on the language, a named type that is defined in
terms of another type may be called a type alias, a subtype,
a constrained type and other terms. A type name declared with
no defining details may be termed an 
\addtoindexx{incomplete type}
incomplete, forward or hidden type. 
While the DWARF \DWTAGtypedef{} entry was
originally inspired by the like named construct in 
\addtoindex{C} and \addtoindex{C++},
it is broadly suitable for similar constructs (by whatever
source syntax) in other languages.}

\section{Array Type Entries}
\label{chap:arraytypeentries}
\label{chap:DWTAGgenericsubrange}

\textit{Many languages share the concept of an \doublequote{array,} which is
\addtoindexx{array type entry}
a table of components of identical type.}

An array type is represented by a debugging information entry
with the tag \DWTAGarraytypeTARG. 
If a name has been given to
\addtoindexx{array!declaration of type}
the array type in the source program, then the corresponding
array type entry has a \DWATname{} attribute 
\addtoindexx{name attribute}
whose value is a
null\dash terminated string containing the array type name as it
appears in the source program.

The 
\hypertarget{chap:DWATorderingarrayrowcolumnordering}{}
array type entry describing a multidimensional array may
\addtoindexx{array!element ordering}
have a \DWATordering{} attribute whose 
\livelink{chap:classconstant}{integer constant} value is
interpreted to mean either row-major or column-major ordering
of array elements. The set of values and their meanings
for the ordering attribute are listed in 
Table \refersec{tab:arrayordering}. 
If no
ordering attribute is present, the default ordering for the
source language (which is indicated by the 
\DWATlanguage{}
attribute 
\addtoindexx{language attribute}
of the enclosing compilation unit entry) is assumed.

\begin{simplenametable}[1.8in]{Array ordering}{tab:arrayordering}
\DWORDcolmajorTARG{} \\
\DWORDrowmajorTARG{} \\
\end{simplenametable}

The ordering attribute may optionally appear on one-dimensional
arrays; it will be ignored.

An array type entry has 
\addtoindexx{type attribute}
a \DWATtype{} attribute
describing
\addtoindexx{array!element type}
the type of each element of the array.

If the amount of storage allocated to hold each element of an
object of the given array type is different from the amount
\addtoindexx{stride attribute|see{bit stride attribute or byte stride attribute}}
of storage that is normally allocated to hold an individual
\hypertarget{chap:DWATbitstridearrayelementstrideofarraytype}{}
object of the 
\hypertarget{chap:DWATbytestridearrayelementstrideofarraytype}{}
indicated element type, then the array type
\addtoindexx{bit stride attribute}
entry has either a 
\DWATbytestride{} 
or 
\addtoindexx{byte stride attribute}
a \DWATbitstride{}
attribute, 
\addtoindexx{bit stride attribute}
whose value 
(see Section \refersec{chap:staticanddynamicvaluesofattributes}) 
is the size of each
element of the array.

The array type entry may have either a \DWATbytesize{} or a
\DWATbitsize{} attribute 
(see Section \refersec{chap:byteandbitsizes}), 
whose value is the
amount of storage needed to hold an instance of the array type.

\textit{If the size of the array can be determined statically at
compile time, this value can usually be computed by multiplying
the number of array elements by the size of each element.}


Each array dimension is described by a debugging information
entry with either the 
\addtoindexx{subrange type entry!as array dimension}
tag \DWTAGsubrangetype{} or the 
\addtoindexx{enumeration type entry!as array dimension}
tag
\DWTAGenumerationtype. These entries are
children of the
array type entry and are ordered to reflect the appearance of
the dimensions in the source program (that is, leftmost dimension
first, next to leftmost second, and so on).

\textit{In languages that have no concept of a 
\doublequote{multidimensional array} (for example, 
\addtoindex{C}), an array of arrays may
be represented by a debugging information entry for a
multidimensional array.}

Alternatively, for an array with dynamic rank the array dimensions 
are described by a debugging information entry with the tag
\DWTAGgenericsubrangeTARG.
This entry has the same attributes as a
\DWTAGsubrangetype{} entry; however,
there is just one \DWTAGgenericsubrangeNAME{} entry and it describes all of the
dimensions of the array.
If \DWTAGgenericsubrangeNAME{}
is used, the number of dimensions must be specified using a
\DWATrank{} attribute. See also Section
\refersec{chap:DWATrank}.


\needlines{5}
Other attributes especially applicable to arrays are
\DWATallocated, 
\DWATassociated{} and 
\DWATdatalocation,
which are described in 
Section \refersec{chap:dynamictypeproperties}. 
For relevant examples, see also Appendix \refersec{app:fortranarrayexample}.

\section{Coarray Type Entries}
\label{chap:coarraytypeentries}
\addtoindexx{coarray}
\textit{In Fortran, a \doublequote{coarray} is an array whose
elements are located in different processes rather than in the
memory of one process. The individual elements
of a coarray can be scalars or arrays.
Similar to arrays, coarrays have \doublequote{codimensions} that are 
indexed using a \doublequote{coindex} or multiple \doublequote{coindices}.
\addtoindexx{codimension|see{coarray}}
\addtoindexx{coindex|see{coarray}}
}

A coarray type is represented by a debugging information entry 
with the tag \DWTAGcoarraytypeTARG.
If a name has been given to the 
coarray type in the source, then the corresponding coarray type 
entry has a \DWATname{} attribute whose value is a null-terminated 
string containing the array type name as it appears in the source 
program.

A coarray entry has one or more \DWTAGsubrangetype{} child entries,
one for each codimension. It also has a \DWATtype{} attribute 
describing the type of each element of the coarray.

\textit{In a coarray application, the run-time number of processes in the application
is part of the coindex calculation.  It is represented in the Fortran source by
a coindex which is declared with a \doublequote{*} as the upper bound.  To express this
concept in DWARF, the \DWTAGsubrangetype{} child entry for that index has 
only a lower bound and no upper bound.}

\textit{How coarray elements are located and how coindices are 
converted to process specifications is processor-dependent.}

\needlines{8}
\section{Structure, Union, Class and Interface Type Entries}
\label{chap:structureunionclassandinterfacetypeentries}

\textit{The languages 
\addtoindex{C}, 
\addtoindex{C++}, and 
\addtoindex{Pascal}, among others, allow the
programmer to define types that are collections of related
\addtoindexx{structure type entry}
components. 
In \addtoindex{C} and \addtoindex{C++}, these collections are called
\doublequote{structures.} 
In \addtoindex{Pascal}, they are called \doublequote{records.}
The components may be of different types. The components are
called \doublequote{members} in \addtoindex{C} and 
\addtoindex{C++}, and \doublequote{fields} in \addtoindex{Pascal}.}

\textit{The components of these collections each exist in their
own space in computer memory. The components of a \addtoindex{C} or \addtoindex{C++}
\doublequote{union} all coexist in the same memory.}

\textit{\addtoindex{Pascal} and 
other languages have a \doublequote{discriminated union,}
\addtoindexx{discriminated union|see {variant entry}}
also called a \doublequote{variant record.} Here, selection of a
number of alternative substructures (\doublequote{variants}) is based
on the value of a component that is not part of any of those
substructures (the \doublequote{discriminant}).}

\textit{\addtoindex{C++} and 
\addtoindex{Java} have the notion of \doublequote{class,} which is in some
ways similar to a structure. A class may have \doublequote{member
functions} which are subroutines that are within the scope
of a class or structure.}

\textit{The \addtoindex{C++} notion of 
structure is more general than in \addtoindex{C}, being
equivalent to a class with minor differences. Accordingly,
in the following discussion statements about 
\addtoindex{C++} classes may
be understood to apply to \addtoindex{C++} structures as well.}

\textit{\addtoindex{C++} has the notion of a "trivial" class, 
whose objects can be bitwise copied. Trivial classes may have 
different rules for passing objects of that type as parameters 
or return values.}

\subsection{Structure, Union and Class Type Entries}
\label{chap:structureunionandclasstypeentries}
Structure, union, and class types are represented by debugging
\addtoindexx{structure type entry}
information entries 
\addtoindexx{union type entry}
with 
\addtoindexx{class type entry}
the tags 
\DWTAGstructuretypeTARG,
\DWTAGuniontypeTARG, 
and \DWTAGclasstypeTARG,
respectively. If a name has been given to the structure,
union, or class in the source program, then the corresponding
structure type, union type, or class type entry has a
\DWATname{} attribute 
\addtoindexx{name attribute}
whose value is a null\dash terminated string
containing the type name as it appears in the source program.

The members of a structure, union, or class are represented
by debugging information entries that are owned by the
corresponding structure type, union type, or class type entry
and appear in the same order as the corresponding declarations
in the source program.

A structure, union, or class type may have a \DWATexportsymbolsNAME{}
attribute 
\livetarg{chap:DWATexportsymbolsofstructunionclass}{}
which indicates that all member names defined within 
the structure, union, or class may be referenced as if they were
defined within the containing structure, union, or class. 

\textit{This may be used to describe anonymous structures, unions 
and classes in \addtoindex{C} or \addtoindex{C++}}.

A structure type, union type or class type entry may have
either a \DWATbytesize{} or a
\DWATbitsize{} attribute 
\hypertarget{chap:DWATbitsizedatamemberbitsize}{}
(see Section \refersec{chap:byteandbitsizes}), 
whose value is the amount of storage needed
to hold an instance of the structure, union or class type,
including any padding.
  
An incomplete structure, union or class type 
\addtoindexx{incomplete structure/union/class}
is 
\addtoindexx{incomplete type}
represented by a structure, union or class
entry that does not have a byte size attribute and that has
\addtoindexx{declaration attribute}
a \DWATdeclaration{} attribute.

If the complete declaration of a type has been placed in
\hypertarget{chap:DWATsignaturetypesignature}{}
a separate \addtoindex{type unit}
(see Section \refersec{chap:separatetypeunitentries}), 
an incomplete declaration 
\addtoindexx{incomplete type}
of that type in the compilation unit may provide
the unique 64\dash bit signature of the type using 
\addtoindexx{type signature}
a \DWATsignature{}
attribute.

If a structure, union or class entry represents the definition
of a structure, union or class member corresponding to a prior
incomplete structure, union or class, the entry may have a
\DWATspecification{} attribute 
\addtoindexx{specification attribute}
whose value is a \livelink{chap:classreference}{reference} to
the debugging information entry representing that incomplete
declaration.

Structure, union and class entries containing the
\DWATspecification{} attribute 
\addtoindexx{specification attribute}
do not need to duplicate
information provided by the declaration entry referenced by the
specification attribute.  In particular, such entries do not
need to contain an attribute for the name of the structure,
union or class they represent if such information is already
provided in the declaration.

\textit{For \addtoindex{C} and \addtoindex{C++}, 
data 
\addtoindexx{data member|see {member entry (data)}}
member declarations occurring within
the declaration of a structure, union or class type are
considered to be \doublequote{definitions} of those members, with
the exception of \doublequote{static} data members, whose definitions
appear outside of the declaration of the enclosing structure,
union or class type. Function member declarations appearing
within a structure, union or class type declaration are
definitions only if the body of the function also appears
within the type declaration.}

If the definition for a given member of the structure, union
or class does not appear within the body of the declaration,
that member also has a debugging information entry describing
its definition. That latter entry has a 
\DWATspecification{} attribute 
\addtoindexx{specification attribute}
referencing the debugging information entry
owned by the body of the structure, union or class entry and
representing a non\dash defining declaration of the data, function
or type member. The referenced entry will not have information
about the location of that member (low and high pc attributes
for function members, location descriptions for data members)
and will have a \DWATdeclaration{} attribute.

\needlines{5}
\textit{Consider a nested class whose 
definition occurs outside of the containing class definition, as in:}

\begin{lstlisting}[numbers=none]
struct A {
    struct B;
};
struct A::B { ... };
\end{lstlisting}

\textit{The two different structs can be described in 
different compilation units to 
facilitate DWARF space compression 
(see Appendix \refersec{app:usingcompilationunits}).}

\needlines{4}
A structure type, union type or class type entry may have a
\DWATcallingconvention{} attribute,
\addtoindexx{calling convention attribute} 
whose value indicates whether a value of the type should be passed by reference 
or passed by value. The set of calling convention codes for use with types 
\addtoindexx{calling convention codes!for types}
\hypertarget{chap:DWATcallingconventionfortypes}{}
is given in Table \referfol{tab:callingconventioncodesfortypes}.

\begin{simplenametable}[2.2in]{Calling convention codes for types}{tab:callingconventioncodesfortypes}
\DWCCnormalTARG             \\
\DWCCpassbyvalueTARG        \\
\DWCCpassbyreferenceTARG    \\
\end{simplenametable}

If this attribute is not present, or its value is
\DWCCnormalNAME, the convention to be used for an object of the
given type is assumed to be unspecified.

\textit{Note that \DWCCnormalNAME{} is also used as a calling convention 
code for certain subprograms 
(see Table \refersec{tab:callingconventioncodesforsubroutines}).}

\textit{If unspecified, a consumer may be able to deduce the calling
convention based on knowledge of the type and the ABI.}


\subsection{Interface Type Entries}
\label{chap:interfacetypeentries}

\textit{The \addtoindex{Java} language defines \doublequote{interface} types. 
An interface
\addtoindexx{interface type entry}
in \addtoindex{Java} is similar to a \addtoindex{C++} or 
\addtoindex{Java} class with only abstract
methods and constant data members.}

Interface types 
\addtoindexx{interface type entry}
are represented by debugging information
entries with the 
tag \DWTAGinterfacetypeTARG.

An interface type entry has 
a \DWATname{} attribute,
\addtoindexx{name attribute}
whose
value is a null\dash terminated string containing the type name
as it appears in the source program.

The members of an interface are represented by debugging
information entries that are owned by the interface type
entry and that appear in the same order as the corresponding
declarations in the source program.

\subsection{Derived or Extended Structs, Classes and Interfaces}
\label{chap:derivedorextendedstructsclasesandinterfaces}

\textit{In \addtoindex{C++}, a class (or struct) 
may 
\addtoindexx{derived type (C++)|see{inheritance entry}}
be \doublequote{derived from} or be a
\doublequote{subclass of} another class. 
In \addtoindex{Java}, an interface may \doublequote{extend}
\addtoindexx{extended type (Java)|see{inheritance entry}}
one 
\addtoindexx{implementing type (Java)|see{inheritance entry}}
or more other interfaces, and a class may \doublequote{extend} another
class and/or \doublequote{implement} one or more interfaces. All of these
relationships may be described using the following. Note that
in \addtoindex{Java}, 
the distinction between extends and implements is
implied by the entities at the two ends of the relationship.}

A class type or interface type entry that describes a
derived, extended or implementing class or interface owns
\addtoindexx{implementing type (Java)|see{inheritance entry}}
debugging information entries describing each of the classes
or interfaces it is derived from, extending or implementing,
respectively, ordered as they were in the source program. Each
such entry has 
\addtoindexx{inheritance entry}
the 
tag \DWTAGinheritanceTARG.

An inheritance entry 
\addtoindexx{type attribute}
has 
\addtoindexx{inheritance entry}
a 
\DWATtype{} attribute whose value is
a reference to the debugging information entry describing the
class or interface from which the parent class or structure
of the inheritance entry is derived, extended or implementing.

An inheritance entry 
\addtoindexx{inheritance entry}
for a class that derives from or extends
\hypertarget{chap:DWATdatamemberlocationinheritedmemberlocation}{}
another class or struct also has 
\addtoindexx{data member location attribute}
a 
\DWATdatamemberlocation{}
attribute, whose value describes the location of the beginning
of the inherited type relative to the beginning address of the
instance of the derived class. If that value is a constant, it is the offset
in bytes from the beginning of the class to the beginning of
the instance of the inherited type. Otherwise, the value must be a location
description. In this latter case, the beginning address of
the instance of the derived class is pushed on the expression stack before
the \addtoindex{location description}
is evaluated and the result of the
evaluation is the location of the instance of the inherited type.

\textit{The interpretation of the value of this attribute for
inherited types is the same as the interpretation for data
members 
(see Section \referfol{chap:datamemberentries}).  }

An 
\addtoindexx{inheritance entry}
inheritance entry 
\hypertarget{chap:DWATaccessibilitycppinheritedmembers}{}
may 
\addtoindexx{accessibility attribute}
have a
\DWATaccessibility{}
attribute. 
If no accessibility attribute
is present, private access is assumed for an entry of a class
and public access is assumed for an entry of an interface,
struct or union.

If 
\hypertarget{chap:DWATvirtualityvirtualityofbaseclass}{}
the class referenced by the 
\addtoindexx{inheritance entry}
inheritance entry serves
as a \addtoindex{C++} virtual base class, the inheritance entry has a
\DWATvirtuality{} attribute.

\textit{For a \addtoindex{C++} virtual base, the 
\addtoindex{data member location attribute}
will usually consist of a non-trivial 
\addtoindex{location description}.}

\subsection{Access Declarations}
\label{chap:accessdeclarations}

\textit{In \addtoindex{C++}, a derived class may contain access declarations that
\addtoindexx{access declaration entry}
change the accessibility of individual class members from the
overall accessibility specified by the inheritance declaration.
A single access declaration may refer to a set of overloaded
names.}

If a derived class or structure contains access declarations,
each such declaration may be represented by a debugging
information entry with the tag 
\DWTAGaccessdeclarationTARG. 
Each
such entry is a child of the class or structure type entry.

An access declaration entry has 
a \DWATname{} attribute, 
\addtoindexx{name attribute}
whose
value is a null\dash terminated string representing the name used
in the declaration in the source program, including any class
or structure qualifiers.

An access declaration entry 
\hypertarget{chap:DWATaccessibilitycppbaseclasses}{}
also 
has a 
\DWATaccessibility{}
attribute describing the declared accessibility of the named
entities.


\needlines{6}
\subsection{Friends}
\label{chap:friends}

Each \doublequote{friend} 
\addtoindexx{friend entry}
declared by a structure, union or class
\hypertarget{chap:DWATfriendfriendrelationship}{}
type may be represented by a debugging information entry
that is a child of the structure, union or class type entry;
the friend entry has the 
tag \DWTAGfriendTARG.

A friend entry has 
\addtoindexx{friend attribute}
a \DWATfriend{} attribute, whose value is
a reference to the debugging information entry describing
the declaration of the friend.


\subsection{Data Member Entries}
\label{chap:datamemberentries}

A data member (as opposed to a member function) is
represented by a debugging information entry with the 
tag \DWTAGmemberTARG. 
The 
\addtoindexx{member entry (data)}
member entry for a named member has
a \DWATname{} attribute 
\addtoindexx{name attribute}
whose value is a null\dash terminated
string containing the member name as it appears in the source
program. If the member entry describes an 
\addtoindex{anonymous union},
the name attribute is omitted or the value of the attribute
consists of a single zero byte.

The data member entry has 
\addtoindexx{type attribute}
a 
\DWATtype{} attribute to denote
\addtoindexx{member entry (data)}
the type of that member.

A data member entry may 
\addtoindexx{accessibility attribute}
have a 
\DWATaccessibility{}
attribute. If no accessibility attribute is present, private
access is assumed for an entry of a class and public access
is assumed for an entry of a structure, union, or interface.

A data member 
\hypertarget{chap:DWATmutablemutablepropertyofmemberdata}{}
entry 
\addtoindexx{member entry (data)}
may 
\addtoindexx{mutable attribute}
have a \DWATmutable{} attribute,
which is a \livelink{chap:classflag}{flag}. 
This attribute indicates whether the data
member was declared with the mutable storage class specifier.

The beginning of a data member 
\addtoindexx{beginning of a data member} 
is described relative to
\addtoindexx{beginning of an object}
the beginning of the object in which it is immediately
contained. In general, the beginning is characterized by
both an address and a bit offset within the byte at that
address. When the storage for an entity includes all of
the bits in the beginning byte, the beginning bit offset is
defined to be zero.

Bit offsets in DWARF use the bit numbering and direction
conventions that are appropriate to the current language on
the target system.

The member entry 
\addtoindexx{member entry (data)}
corresponding to a data member that is
\hypertarget{chap:DWATdatabitoffsetdatamemberbitlocation}{}
defined 
\hypertarget{chap:DWATdatamemberlocationdatamemberlocation}{}
in a structure, union or class may have either
\addtoindexx{data member location attribute}
a
\DWATdatamemberlocation{} attribute or a
\DWATdatabitoffset{}
attribute. If the beginning of the data member is the same as
the beginning of the containing entity then neither attribute
is required.

\needlines{4}
For a \DWATdatamemberlocation{} attribute
\addtoindexx{data member location attribute}
there are two cases:
\begin{enumerate}[1. ]
\item If the value is an \livelink{chap:classconstant}{integer constant}, 
it is the offset
in bytes from the beginning of the containing entity. If
the beginning of the containing entity has a non-zero bit
offset then the beginning of the member entry has that same
bit offset as well.

\item Otherwise, the value must be a \addtoindex{location description}.
In
this case, the beginning of the containing entity must be byte
aligned. The beginning address is pushed on the DWARF stack
before the \addtoindex{location} description is evaluated; the result of
the evaluation is the base address of the member entry.

\textit{The push on the DWARF expression stack of the base address of
the containing construct is equivalent to execution of the
\DWOPpushobjectaddress{} operation 
(see Section \refersec{chap:stackoperations});
\DWOPpushobjectaddress{} therefore 
is not needed at the
beginning of a \addtoindex{location description} for a data member. 
The
result of the evaluation is a location---either an address or
the name of a register, not an offset to the member.}

\textit{A \DWATdatamemberlocation{} 
attribute 
\addtoindexx{data member location attribute}
that has the form of a
\addtoindex{location description} is not valid for a data member contained
in an entity that is not byte aligned because DWARF operations
do not allow for manipulating or computing bit offsets.}

\end{enumerate}

\needlines{4}
For a \DWATdatabitoffset{} attribute, 
the value is an \livelink{chap:classconstant}{integer constant} 
(see Section \refersec{chap:staticanddynamicvaluesofattributes}) 
that specifies the number of bits
from the beginning of the containing entity to the beginning
of the data member. This value must be greater than or equal
to zero, but is not limited to less than the number of bits
per byte.

If the size of a data member is not the same as the size
of the type given for the data member, the data member has
\addtoindexx{bit size attribute}
either a \DWATbytesize{} 
or a \DWATbitsize{} attribute whose
\livelink{chap:classconstant}{integer constant} value 
(see Section \refersec{chap:staticanddynamicvaluesofattributes}) 
is the amount
of storage needed to hold the value of the data member.

\textit{Bit fields in \addtoindex{C} and \addtoindex{C++} 
typically 
\addtoindexx{bit fields} 
require the use 
\addtoindexx{data bit offset}
of 
\addtoindexx{data bit size}
the
\DWATdatabitoffset{} and 
\DWATbitsize{} attributes.}

\needlines{6}
\textit{This Standard uses the following bit numbering and direction
conventions in examples. These conventions are for illustrative
purposes and other conventions may apply on particular
architectures.}
\begin{itemize}
\item \textit{For big\dash endian architectures, bit offsets are
counted from high-order to low\dash order bits within a byte (or
larger storage unit); in this case, the bit offset identifies
the high\dash order bit of the object.}

\item \textit{For little\dash endian architectures, bit offsets are
counted from low\dash order to high\dash order bits within a byte (or
larger storage unit); in this case, the bit offset identifies
the low\dash order bit of the object.}
\end{itemize}


\textit{In either case, the bit so identified is defined as the 
\addtoindexx{beginning of an object}
beginning of the object.}

\needlines{5}
\textit{For example, take one possible representation of the following 
\addtoindex{C} structure definition 
in both big\dash and little\dash endian byte orders:}

\begin{lstlisting}
struct S {
    int j:5;
    int k:6;
    int m:5;
    int n:8;
};
\end{lstlisting}

\textit{Figures \referfol{fig:bigendiandatabitoffsets} and
\refersec{fig:littleendiandatabitoffsets}
show the structure layout
and data bit offsets for example big\dash\   and little\dash endian
architectures, respectively. Both diagrams show a structure
that begins at address A and whose size is four bytes. Also,
high order bits are to the left and low order bits are to
the right.}

\begin{figure}[h]
\begin{dwflisting}
\begin{verbatim}

    j:0
    k:5
    m:11
    n:16

    Addresses increase ->
    |       A       |     A + 1     |    A + 2      |    A + 3      | 

    Data bit offsets increase ->
    +---------------+---------------+---------------+---------------+
    |0     4|5         10|11      15|16           23|24           31|
    |   j   |     k      | m        |        n      |       <pad>   |
    |       |            |          |               |               | 
    +---------------------------------------------------------------+ 

\end{verbatim}
\end{dwflisting}
\caption{Big-endian data bit offsets}
\label{fig:bigendiandatabitoffsets}
\end{figure}

\begin{figure}[h]
\begin{dwflisting}
\begin{verbatim}

    j:0
    k:5
    m:11
    n:16
                                               <- Addresses increase
    |     A + 3     |     A + 2     |    A + 1      |       A       | 

                                        <-  Data bit offsets increase 
    +---------------+---------------+---------------+---------------+
    |31           24|23           16|15     11|10       5|4        0|
    |     <pad>     |        n      |    m    |    k     |     j    |
    |               |               |         |          |          |
    +---------------------------------------------------------------+

\end{verbatim}
\end{dwflisting}
\caption{Little-endian data bit offsets}
\label{fig:littleendiandatabitoffsets}
\end{figure}

\needlines{4}
\textit{Note that data member bit offsets in this example are the
same for both big\dash\ and little\dash endian architectures even
though the fields are allocated in different directions
(high\dash order to low-order versus low\dash order to high\dash order);
the bit naming conventions for memory and/or registers of
the target architecture may or may not make this seem natural.}

\textit{For a more extensive example showing nested and packed records
and arrays, see 
Appendix \refersec{app:pascalexample}.}

\needlines{4}
\textit{Attribute \DWATdatabitoffset{} 
is new in 
\addtoindex{DWARF Version 4}, unchanged in \addtoindex{DWARF Version 5},
and is also used for base types 
(see Section 
\refersec{chap:basetypeentries}). 
It replaces the
\livetarg{chap:DWATbitoffsetdatamemberbitlocation}{}
attributes \DWATbitoffset{} and
\DWATbytesize{} when used to
identify the beginning of bit field data members as defined
in DWARF V3 and earlier. The \DWATbytesize, 
\DWATbitsize{} and 
\DWATbitoffset{}
attribute combination is deprecated for data members in DWARF
Version 4 and later. See Section 5.6.6 in the DWARF Version 4
specification for a discussion of compatibility considerations.}

\subsection{Member Function Entries}
\label{chap:memberfunctionentries}

A member function is represented by a 
\addtoindexx{member function entry}
debugging information entry 
with the 
\addtoindexx{subprogram entry!as member function}
tag \DWTAGsubprogram.
The member function entry
may contain the same attributes and follows the same rules
as non\dash member global subroutine entries 
(see Section \refersec{chap:subroutineandentrypointentries}).

\needlines{4}
\textit{In particular, if the member function entry is an
instantiation of a member function template, it follows the 
same rules as function template instantiations (see Section 
\refersec{chap:functiontemplateinstantiations}).
}

A 
\addtoindexx{accessibility attribute}
member function entry may have a 
\DWATaccessibility{}
attribute. If no accessibility attribute is present, private
access is assumed for an entry of a class and public access
is assumed for an entry of a structure, union or interface.

If 
\hypertarget{chap:DWATvirtualityvirtualityoffunction}{}
the member function entry describes a virtual function,
then that entry has a 
\DWATvirtuality{} attribute.

If 
\hypertarget{chap:DWATexplicitexplicitpropertyofmemberfunction}{}
the member function entry describes an explicit member
function, then that entry has 
\addtoindexx{explicit attribute}
a 
\DWATexplicit{} attribute.

An 
\hypertarget{chap:DWATvtableelemlocationvirtualfunctiontablevtableslot}{}
entry for a virtual function also has a
\DWATvtableelemlocation{}
\addtoindexi{attribute}{vtable element location attribute} whose value contains
a \addtoindex{location description} 
yielding the address of the slot
for the function within the virtual function table for the
enclosing class. The address of an object of the enclosing
type is pushed onto the expression stack before the location
description is evaluated.

If 
\hypertarget{chap:DWATobjectpointerobjectthisselfpointerofmemberfunction}{}
the member function entry describes a non\dash static member
\addtoindexx{this pointer attribute|see{object pointer attribute}}
function, then that entry 
\addtoindexx{self pointer attribute|see{object pointer attribute}}
has 
\addtoindexx{object pointer attribute}
a \DWATobjectpointer{} 
attribute
whose value is a \livelink{chap:classreference}{reference} 
to the formal parameter entry
that corresponds to the object for which the function is
called. The name attribute of that formal parameter is defined
by the current language (for example, 
\texttt{this} for \addtoindex{C++} or \texttt{self}
for \addtoindex{Objective C} 
and some other languages). That parameter
also has a \DWATartificial{} attribute whose value is true.

Conversely, if the member function entry describes a static
member function, the entry does not have 
\addtoindexx{object pointer attribute}
a 
\DWATobjectpointer{}
attribute.

\textit{In \addtoindex{C++}, non-static member functions can have const-volatile
qualifiers, which affect the type of the first formal parameter (the
\doublequote{\texttt{this}}-pointer).}
 
If the member function entry describes a non\dash static member
function that has a const\dash volatile qualification, then
the entry describes a non\dash static member function whose
object formal parameter has a type that has an equivalent
const\dash volatile qualification.

\textit{In \addtoindex{C++:2011 (ISO)}, non-static member functions can also have one of the
ref-qualifiers, \& and \&\&. They do not change the type of the
\doublequote{\texttt{this}}-pointer, but they affect the types of object values the
function can be invoked on.}

The member function entry may have an \DWATreferenceNAME{} attribute
\livetarg{chap:DWATreferenceofnonstaticmember}{}
to indicate a non-static member function that can only be called on
l-value objects, or the \DWATrvaluereferenceNAME{} attribute 
\livetarg{chap:DWATrvaluereferenceofnonstaticmember}{}
to indicate that it can only be called on pr-values and x-values.

If a subroutine entry represents the defining declaration
of a member function and that definition appears outside of
the body of the enclosing class declaration, the subroutine
entry has a 
\DWATspecification{} attribute, 
\addtoindexx{specification attribute}
whose value is
a reference to the debugging information entry representing
the declaration of this function member. The referenced entry
will be a child of some class (or structure) type entry.

Subroutine entries containing the
\DWATspecification{} attribute 
\addtoindexx{specification attribute}
do not need to duplicate information provided
by the declaration entry referenced by the specification
attribute. In particular, such entries do not need to contain
a name attribute giving the name of the function member whose 
definition they represent.  
Similarly, such entries do not need to contain a return type 
attribute, unless the return type on the declaration was 
unspecified (for example, the declaration used the 
\addtoindex{C++} \autoreturntype{} specifier).

\textit{In \addtoindex{C++}, a member function may be declared 
as deleted. This prevents the compiler from generating a default
implementation of a special member function such as a
constructor or destructor, and can affect overload resolution
when used on other member functions.}

If the member function entry has been declared as deleted,
\hypertarget{chap:DWATdeleted}{}
then that entry has a \DWATdeletedTARG{} attribute.\addtoindexx{deleted attribute}

\textit{In \addtoindex{C++}, a special member function may be 
declared as defaulted, which explicitly declares a default
compiler-generated implementation of the function. The
declaration may have different effects on the calling
convention used for objects of its class, depending on
whether the default declaration is made inside or outside the
class.}

If the member function has been declared as defaulted, 
then the entry has a \DWATdefaultedTARG{} 
attribute\addtoindexx{defaulted attribute}
whose integer constant value indicates whether, and if so,
how, that member is defaulted. The possible values and
their meanings are shown in 
Table \referfol{tab:defaultedattributevaluenames}.

\begin{centering}
  \setlength{\extrarowheight}{0.1cm}
\begin{longtable}{l|l}
  \caption{Defaulted attribute names} \label{tab:defaultedattributevaluenames} \\
  \hline \bfseries Defaulted attribute name & \bfseries Meaning \\ \hline
\endfirsthead
  \bfseries Defaulted attribute name & \bfseries Meaning \\ \hline
\endhead
  \hline \emph{Continued on next page}
\endfoot
\endlastfoot
\DWDEFAULTEDnoTARG        & Not declared default \\
\DWDEFAULTEDinclassTARG   & Defaulted within the class \\
\DWDEFAULTEDoutofclassTARG& Defaulted outside of the class \\
\hline
\end{longtable}
\end{centering}

\textit{An artificial member function (that is, a compiler-generated
copy that does not appear in the source) does not have a
\DWATdefaultedNAME{} attribute.}

\needlines{5}
\subsection{Class Template Instantiations}
\label{chap:classtemplateinstantiations}

\textit{In \addtoindex{C++} a class template is a generic definition of a class
type that may be instantiated when an instance of the class
is declared or defined. The generic description of the class may include
parameterized types, parameterized compile-time constant
values, and/or parameterized run-time constant addresses. 
DWARF does not represent the generic template
definition, but does represent each instantiation.}

A class template instantiation is represented by a
debugging information entry with the tag \DWTAGclasstype,
\DWTAGstructuretype{} or 
\DWTAGuniontype. With the following
exceptions, such an entry will contain the same attributes
and have the same types of child entries as would an entry
for a class type defined explicitly using the instantiation
types and values. The exceptions are:

\begin{enumerate}[1. ]
\item Template parameters are described and referenced as
specified in Section \refersec{chap:templateparameters}.

\needlines{4}
\item If the compiler has generated a special compilation unit to
hold the 
\addtoindexx{template instantiation!and special compilation unit}
template instantiation and that special compilation
unit has a different name from the compilation unit containing
the template definition, the name attribute for the debugging
information entry representing the special compilation unit
should be empty or omitted.

\needlines{4}
\item If the class type entry representing the template
instantiation or any of its child entries contains declaration
coordinate attributes, those attributes should refer to
the source for the template definition, not to any source
generated artificially by the compiler.
\end{enumerate}


\subsection{Variant Entries}
\label{chap:variantentries}

A variant part of a structure is represented by a debugging
information entry\addtoindexx{variant part entry} with the 
tag \DWTAGvariantpartTARG{} and is
owned by the corresponding structure type entry.

If the variant part has a discriminant, the discriminant is
\hypertarget{chap:DWATdiscrdiscriminantofvariantpart}{}
represented by a 
\addtoindexx{discriminant (entry)}
separate debugging information entry which
is a child of the variant part entry. This entry has the form
of a 
\addtoindexx{member entry (data)!as discriminant}
structure data member entry. The variant part entry will
\addtoindexx{discriminant attribute}
have a 
\DWATdiscr{} attribute 
whose value is a \livelink{chap:classreference}{reference} to
the member entry for the discriminant.

If the variant part does not have a discriminant (tag field),
the variant part entry has 
\addtoindexx{type attribute}
a 
\DWATtype{} attribute to represent
the tag type.

Each variant of a particular variant part is represented by
\hypertarget{chap:DWATdiscrvaluediscriminantvalue}{}
a debugging information entry\addtoindexx{variant entry} with the 
tag \DWTAGvariantTARG{}
and is a child of the variant part entry. The value that
selects a given variant may be represented in one of three
ways. The variant entry may have a 
\DWATdiscrvalue{} attribute
whose value represents a single case label. The value of this
attribute is encoded as an LEB128 number. The number is signed
if the tag type for the variant part containing this variant
is a signed type. The number is unsigned if the tag type is
an unsigned type.

\needlines{5}
Alternatively, 
\hypertarget{chap:DWATdiscrlistlistofdiscriminantvalues}{}
the variant entry may contain 
\addtoindexx{discriminant list attribute}
a 
\DWATdiscrlist{}
attribute, whose value represents a list of discriminant
values. This list is represented by any of the 
\livelink{chap:classblock}{block} forms and
may contain a mixture of case labels and label ranges. Each
item on the list is prefixed with a discriminant value
descriptor that determines whether the list item represents
a single label or a label range. A single case label is
represented as an LEB128 number as defined above for 
\addtoindexx{discriminant value attribute}
the
\DWATdiscrvalue{} 
attribute. A label range is represented by
two LEB128 numbers, the low value of the range followed by the
high value. Both values follow the rules for signedness just
described. The discriminant value descriptor is an integer
constant that may have one of the values given in 
Table \refersec{tab:discriminantdescriptorvalues}.

\begin{simplenametable}[1.4in]{Discriminant descriptor values}{tab:discriminantdescriptorvalues}
\DWDSClabelTARG{} \\
\DWDSCrangeTARG{} \\
\end{simplenametable}

If a variant entry has neither a \DWATdiscrvalue{}
attribute nor a \DWATdiscrlist{} attribute, or if it has
a \DWATdiscrlist{} attribute with 0 size, the variant is a
default variant.

The components selected by a particular variant are represented
by debugging information entries owned by the corresponding
variant entry and appear in the same order as the corresponding
declarations in the source program.

\needlines{6}
\section{Condition Entries}
\label{chap:conditionentries}

\textit{COBOL has the notion of 
\addtoindexx{level-88 condition, COBOL}
a \doublequote{level\dash 88 condition} that
associates a data item, called the conditional variable, with
a set of one or more constant values and/or value ranges.
% Note: the {} after \textquoteright (twice) is necessary to assure a following space separator
Semantically, the condition is \textquoteleft true\textquoteright{}
if the conditional
variable's value matches any of the described constants,
and the condition is \textquoteleft false\textquoteright{} otherwise.}

The \DWTAGconditionTARG{}
debugging information entry\addtoindexx{condition entry}
describes a
logical condition that tests whether a given data item\textquoteright s
value matches one of a set of constant values. If a name
has been given to the condition, the condition entry has a
\DWATname{} attribute
\addtoindexx{name attribute}
whose value is a null\dash terminated string
giving the condition name as it appears in the source program.

\needlines{4}
The condition entry's parent entry describes the conditional
variable; normally this will be a \DWTAGvariable,
\DWTAGmember{} or 
\DWTAGformalparameter{} entry.
If 
\addtoindexx{formal parameter entry}
the parent
entry has an array type, the condition can test any individual
element, but not the array as a whole. The condition entry
implicitly specifies a \doublequote{comparison type} that is the
type of an array element if the parent has an array type;
otherwise it is the type of the parent entry.

\needlines{4}
The condition entry owns \DWTAGconstant{} and/or
\DWTAGsubrangetype{} entries that describe the constant
values associated with the condition. If any child entry 
\addtoindexx{type attribute}
has
a \DWATtype{} attribute,
that attribute should describe a type
compatible with the comparison type (according to the source
language); otherwise the child\textquoteright s type is the same as the
comparison type.

\textit{For conditional variables with alphanumeric types, COBOL
permits a source program to provide ranges of alphanumeric
constants in the condition. Normally a subrange type entry
does not describe ranges of strings; however, this can be
represented using bounds attributes that are references to
constant entries describing strings. A subrange type entry may
refer to constant entries that are siblings of the subrange
type entry.}


\section{Enumeration Type Entries}
\label{chap:enumerationtypeentries}

\textit{An \doublequote{enumeration type} is a scalar that can assume one of
a fixed number of symbolic values.}

An enumeration type is represented by a debugging information
entry with the tag 
\DWTAGenumerationtypeTARG.

If a name has been given to the enumeration type in the source
program, then the corresponding enumeration type entry has
a \DWATname{} attribute
\addtoindexx{name attribute}
whose value is a null\dash terminated
string containing the enumeration type name as it appears
in the source program. 

The \addtoindex{enumeration type entry}
may have 
\addtoindexx{type attribute}
a \DWATtype{} attribute
which refers to the underlying data type used to implement
the enumeration. The entry also may have a 
\DWATbytesize{} attribute whose 
\livelink{chap:classconstant}{integer constant} value is the number of bytes 
required to hold an instance of the enumeration. If no \DWATbytesize{} attribute 
is present, the size for holding an instance of the enumeration is given by the size 
of the underlying data type.

\needlines{4}
If an enumeration type has type safe 
\addtoindexx{type safe enumeration types}
semantics such that

\begin{enumerate}[1. ]
\item Enumerators are contained in the scope of the enumeration type, and/or

\item Enumerators are not implicitly converted to another type
\end{enumerate}

then the \addtoindex{enumeration type entry} may 
\addtoindexx{enum class|see{type-safe enumeration}}
have a \DWATenumclass{}
attribute, which is a \livelink{chap:classflag}{flag}. 
In a language that offers only
one kind of enumeration declaration, this attribute is not
required.

\textit{In \addtoindex{C} or \addtoindex{C++}, 
the underlying type will be the appropriate
integral type determined by the compiler from the properties of
\hypertarget{chap:DWATenumclasstypesafeenumerationdefinition}{}
the enumeration literal values. 
A \addtoindex{C++} type declaration written
using enum class declares a strongly typed enumeration and
is represented using \DWTAGenumerationtype{} 
in combination with \DWATenumclass.}

Each enumeration literal is represented by a debugging
\addtoindexx{enumeration literal|see{enumeration entry}}
information entry with the 
tag \DWTAGenumeratorTARG. 
Each
such entry is a child of the 
\addtoindex{enumeration type entry}, and the
enumerator entries appear in the same order as the declarations
of the enumeration literals in the source program.

Each \addtoindex{enumerator entry} has a 
\DWATname{} attribute, whose
\addtoindexx{name attribute}
value is a null\dash terminated string containing the name of the
\hypertarget{chap:DWATconstvalueenumerationliteralvalue}{}
enumeration literal as it appears in the source program. 
Each enumerator entry also has a 
\DWATconstvalue{} attribute,
whose value is the actual numeric value of the enumerator as
represented on the target system.


If the enumeration type occurs as the description of a
\addtoindexx{enumeration type entry!as array dimension}
dimension of an array type, and the stride for that dimension
\hypertarget{chap:DWATbytestrideenumerationstridedimensionofarraytype}{}
is different than what would otherwise be determined, then
\hypertarget{chap:DWATbitstrideenumerationstridedimensionofarraytype}{}
the enumeration type entry has either a 
\DWATbytestride{}
or \DWATbitstride{} attribute 
\addtoindexx{bit stride attribute}
which specifies the separation
between successive elements along the dimension as described
in 
Section \refersec{chap:staticanddynamicvaluesofattributes}. 
The value of the 
\DWATbitstride{} attribute
\addtoindexx{bit stride attribute}
is interpreted as bits and the value of 
\addtoindexx{byte stride attribute}
the 
\DWATbytestride{}
attribute is interpreted as bytes.


\section{Subroutine Type Entries}
\label{chap:subroutinetypeentries}

\textit{It is possible in \addtoindex{C}
to declare pointers to subroutines
that return a value of a specific type. In both 
\addtoindex{C} and \addtoindex{C++},
it is possible to declare pointers to subroutines that not
only return a value of a specific type, but accept only
arguments of specific types. The type of such pointers would
be described with a \doublequote{pointer to} modifier applied to a
user\dash defined type.}

\needlines{4}
A subroutine type is represented by a debugging information
entry with the 
\addtoindexx{subroutine type entry}
tag \DWTAGsubroutinetypeTARG. 
If a name has
been given to the subroutine type in the source program,
then the corresponding subroutine type entry has 
a \DWATname{} attribute 
\addtoindexx{name attribute}
whose value is a null\dash terminated string containing
the subroutine type name as it appears in the source program.

If the subroutine type describes a function that returns
a value, then the subroutine type entry has 
\addtoindexx{type attribute}
a \DWATtype{}
attribute to denote the type returned by the subroutine. If
the types of the arguments are necessary to describe the
subroutine type, then the corresponding subroutine type
entry owns debugging information entries that describe the
arguments. These debugging information entries appear in the
order that the corresponding argument types appear in the
source program.

\textit{In \addtoindex{C} there 
is a difference between the types of functions
declared using function prototype style declarations and
those declared using non\dash prototype declarations.}

A 
\hypertarget{chap:DWATprototypedsubroutineprototype}{}
subroutine entry declared with a function prototype style
declaration may have 
\addtoindexx{prototyped attribute}
a 
\DWATprototyped{} attribute, which is
a \livelink{chap:classflag}{flag}.

Each debugging information entry owned by a subroutine
type entry corresponds to either a formal parameter or the sequence of
unspecified parameters of the subprogram type:

\begin{enumerate}[1. ]
\item A formal parameter of a parameter list (that has a
specific type) is represented by a debugging information entry
with the tag \DWTAGformalparameter. 
Each formal parameter
entry has 
\addtoindexx{type attribute}
a \DWATtype{} attribute that refers to the type of
the formal parameter.

\item The unspecified parameters of a variable parameter list
\addtoindexx{unspecified parameters entry}
are 
\addtoindexx{\texttt{...} parameters|see{unspecified parameters entry}}
represented by a debugging information entry with the
tag \DWTAGunspecifiedparameters.
\end{enumerate}

\textit{\addtoindex{C++} const-volatile qualifiers are encoded as 
part of the type of the
\doublequote{\texttt{this}}-pointer. 
\addtoindex{C++:2011 (ISO)} reference and rvalue-reference qualifiers are encoded using
the \DWATreference{} and \DWATrvaluereference{} attributes, respectively. 
See also Section \refersec{chap:memberfunctionentries}.}

\needlines{4}
A subroutine type entry may have the \DWATreference{} or
\DWATrvaluereference{} attribute to indicate that it describes the
type of a member function with reference or rvalue-reference 
semantics, respectively.

\needlines{6}
\section{String Type Entries}
\label{chap:stringtypeentries}

\textit{A \doublequote{string} is a sequence of characters that have specific
\addtoindexx{string type entry}
semantics and operations that distinguish them from arrays of
characters. 
\addtoindex{Fortran} is one of the languages that has a string
type. Note that \doublequote{string} in this context refers to a target
machine concept, not the class string as used in this document
(except for the name attribute).}

A string type is represented by a debugging information entry
with the tag \DWTAGstringtypeTARG. 
If a name has been given to
the string type in the source program, then the corresponding
string type entry has a 
\DWATname{} attribute
\addtoindexx{name attribute}
whose value is
a null\dash terminated string containing the string type name as
it appears in the source program.

\textit{The 
\addtoindex{Fortran 2003} language standard allows string 
types that are composed of different types of (same sized) characters. 
While there is no standard list of character kinds, the kinds
\texttt{ASCII}\index{ASCII@\texttt{ASCII} (Fortran string kind)} (see \DWATEASCII), 
\texttt{ISO\_10646}\index{ISO\_10646@\texttt{ISO\_10646} (Fortran string kind)}
\addtoindexx{ISO 10646 character set standard}
(see \DWATEUCS) and 
\texttt{DEFAULT}\index{DEFAULT@\texttt{DEFAULT} (Fortran string kind)}
are defined.}

A string type entry may have a \DWATtype{} 
\livetargi{char:DWAATtypeofstringtype}{attribute}{type attribute!of string type entry}
describing how each character is encoded and is to be interpreted.  
The value of this attribute is a \CLASSreference to a 
\DWTAGbasetype{} base type entry.  If the attribute is absent, 
then the character is encoded using the system default.

\needlines{4}
The string type entry may have a 
\DWATbytesize{} attribute or 
\DWATbitsize{}
attribute, whose value 
(see Section \refersec{chap:byteandbitsizes}) 
is the amount of
storage needed to hold a value of the string type.

The 
\hypertarget{chap:DWATstringlengthstringlengthofstringtype}{}
string type entry may also have a 
\DWATstringlength{} attribute
whose 
\addtoindexx{string length attribute}
value is a 
\addtoindex{location description} yielding the location
where the length of the string is stored in the program.
If the \DWATstringlength{} attribute is not present, the size
of the string is assumed to be the amount of storage that is
allocated for the string (as specified by the \DWATbytesize{}
or \DWATbitsize{} attribute).

The string type entry may also have a 
\DWATstringlengthbytesizeNAME{}
attribute or
\DWATstringlengthbitsizeNAME{} attribute,
\addtoindexx{string length attribute!size of length data}
whose value (see Section \refersec{chap:byteandbitsizes}) 
is the size of the data to be retrieved from the location
referenced by the string length attribute. If no (byte or bit)
size attribute is present, the size of the data to be retrieved
is the same as the 
\addtoindex{size of an address} on the target machine.

\needlines{8}
\addtoindexx{DWARF Version 5}   % Avoid italics
\textit{Prior to DWARF Version 5, the meaning of a 
\DWATbytesize{} attribute depends on the presence of the
\DWATstringlength{} attribute:
\begin{itemize}
\item If \DWATstringlength{} is present, \DWATbytesize{} 
        specifies the size of the length data to be retrieved 
        from the location specified by the \DWATstringlength{} attribute.
\item If \DWATstringlength{} is not present, \DWATbytesize{}
        specifies the amount of storage allocated for objects
        of the string type.
\end{itemize}
In DWARF Version 5, \DWATbytesize{} always specifies the amount of storage 
allocated for objects of the string type.}

\needlines{6}
\section{Set Type Entries}
\label{chap:settypeentries}

\textit{\addtoindex{Pascal} provides the concept of a \doublequote{set,} which represents
a group of values of ordinal type.}

A set is represented by a debugging information entry with
the tag \DWTAGsettypeTARG. 
\addtoindexx{set type entry}
If a name has been given to the
set type, then the set type entry has 
a \DWATname{} attribute
\addtoindexx{name attribute}
whose value is a null\dash terminated string containing the
set type name as it appears in the source program.

The set type entry has 
\addtoindexx{type attribute}
a \DWATtype{} attribute to denote the
type of an element of the set.

\needlines{4}
If the amount of storage allocated to hold each element of an
object of the given set type is different from the amount of
storage that is normally allocated to hold an individual object
of the indicated element type, then the set type entry has
either a \DWATbytesize{} attribute, or 
\DWATbitsize{} attribute
whose value (see Section \refersec{chap:byteandbitsizes}) is
the amount of storage needed to hold a value of the set type.


\section{Subrange Type Entries}
\label{chap:subrangetypeentries}

\textit{Several languages support the concept of a \doublequote{subrange}
type object. These objects can represent a subset of the
values that an object of the basis type for the subrange can
represent. 
Subrange type entries may also be used to represent
the bounds of array dimensions.}

A subrange type is represented by a debugging information
entry with the 
\addtoindexx{subrange type entry}
tag \DWTAGsubrangetypeTARG. 
If a name has been
given to the subrange type, then the subrange type entry
has a \DWATname{} attribute
\addtoindexx{name attribute}
whose value is a null\dash terminated
string containing the subrange type name as it appears in
the source program.

The tag \DWTAGgenericsubrange{} is
used to describe arrays with a dynamic rank. See Section
\refersec{chap:DWTAGgenericsubrange}.

The subrange entry may have 
\addtoindexx{type attribute}
a \DWATtype{} attribute to describe
the type of object, called the basis type, of whose values
this subrange is a subset.

If the amount of storage allocated to hold each element of an
object of the given subrange type is different from the amount
of storage that is normally allocated to hold an individual
object of the indicated element type, then the subrange
type entry has a 
\DWATbytesize{} attribute or 
\DWATbitsize{}
attribute, whose value 
(see Section \refersec{chap:staticanddynamicvaluesofattributes})
is the amount of
storage needed to hold a value of the subrange type.

The 
\hypertarget{chap:DWATthreadsscaledupcarrayboundthreadsscalfactor}{}
subrange entry may have 
\addtoindexx{threads scaled attribute}
a 
\DWATthreadsscaled{} attribute,
which is a \livelink{chap:classflag}{flag}. 
If present, this attribute indicates whether
this subrange represents a \addtoindex{UPC} array bound which is scaled
by the runtime THREADS value (the number of \addtoindex{UPC} threads in
this execution of the program).

\textit{This allows the representation of a \addtoindex{UPC} shared array such as}

\begin{lstlisting}[numbers=none]
int shared foo[34*THREADS][10][20];
\end{lstlisting}

The 
\hypertarget{chap:DWATlowerboundlowerboundofsubrange}{}
subrange 
\hypertarget{chap:DWATupperboundupperboundofsubrange}{}
entry may have the attributes 
\DWATlowerbound{}
\addtoindexx{lower bound attribute}
and \DWATupperbound{}
\addtoindexx{upper bound attribute} to specify, respectively, the lower
and upper bound values of the subrange. The 
\DWATupperbound{}
attribute 
\hypertarget{chap:DWATcountelementsofsubrangetype}{}
may 
% FIXME: The following matches DWARF4: odd as there is no default count.
\addtoindexx{count attribute!default}
be 
\addtoindexx{count attribute}
replaced by a 
\DWATcount{} attribute, 
whose
value describes the number of elements in the subrange rather
than the value of the last element. The value of each of
these attributes is determined as described in 
Section \refersec{chap:staticanddynamicvaluesofattributes}.

If the lower bound value is missing, the value is assumed to
be a language\dash dependent default constant as defined in
Table \refersec{tab:languageencodings}.
\addtoindexx{lower bound attribute!default}

If the upper bound and count are missing, then the upper bound value is 
\textit{unknown}.\addtoindexx{upper bound attribute!default unknown}

If the subrange entry has no type attribute describing the
basis type, the basis type is determined as follows:
\begin{enumerate}[1. ]
\item
If there is a lower bound attribute that references an object,
the basis type is assumed to be the same as the type of that object.
\item
Otherwise, if there is an upper bound or count attribute that references
an object, the basis type is assumed to be the same as the type of that object.
\item
Otherwise, the type is
assumed to be the same type, in the source language of the
compilation unit containing the subrange entry, as a signed
integer with the same size as an address on the target machine.
\end{enumerate}

If the subrange type occurs as the description of a dimension
of an array type, and the stride for that dimension is
\hypertarget{chap:DWATbytestridesubrangestridedimensionofarraytype}{}
different than what would otherwise be determined, then
\hypertarget{chap:DWATbitstridesubrangestridedimensionofarraytype}{}
the subrange type entry has either 
\addtoindexx{byte stride attribute}
a 
\DWATbytestride{} or
\DWATbitstride{} attribute 
\addtoindexx{bit stride attribute}
which specifies the separation
between successive elements along the dimension as described
in 
Section \refersec{chap:byteandbitsizes}.

\textit{Note that the stride can be negative.}

\needlines{4}
\section{Pointer to Member Type Entries}
\label{chap:pointertomembertypeentries}

\textit{In \addtoindex{C++}, a 
pointer to a data or function member of a class or
structure is a unique type.}

A debugging information entry representing the type of an
object that is a pointer to a structure or class member has
the tag \DWTAGptrtomembertypeTARG.

If the \addtoindex{pointer to member type} has a name, the 
\addtoindexx{pointer to member type entry}
pointer to member entry has a
\DWATname{} attribute, 
\addtoindexx{name attribute}
whose value is a
null\dash terminated string containing the type name as it appears
in the source program.

The \addtoindex{pointer to member} entry 
has 
\addtoindexx{type attribute}
a \DWATtype{} attribute to
describe the type of the class or structure member to which
objects of this type may point.

The \addtoindexx{pointer to member} entry also 
\hypertarget{chap:DWATcontainingtypecontainingtypeofpointertomembertype}{}
has a 
\DWATcontainingtype{}
attribute, whose value is a \livelink{chap:classreference}{reference} to a debugging
information entry for the class or structure to whose members
objects of this type may point.

The \addtoindex{pointer to member entry} 
\hypertarget{chap:DWATuselocationmemberlocationforpointertomembertype}{}
has a 
\DWATuselocation{} attribute
\addtoindexx{use location attribute}
whose value is a 
\addtoindex{location description} that computes the
address of the member of the class to which the pointer to
member entry points.

\textit{The method used to find the address of a given member of a
class or structure is common to any instance of that class
or structure and to any instance of the pointer or member
type. The method is thus associated with the type entry,
rather than with each instance of the type.}

The \DWATuselocation{} description is used in conjunction
with the location descriptions for a particular object of the
given \addtoindex{pointer to member type} and for a particular structure or
class instance. The \DWATuselocation{} 
attribute expects two values to be 
\addtoindexi{pushed}{address!implicit push for member operator}
onto the DWARF expression stack before
the \DWATuselocation{} description is evaluated.
The first value 
\addtoindexi{pushed}{address!implicit push for member operator}
is the value of the \addtoindex{pointer to member} object
itself. The second value 
\addtoindexi{pushed}{address!implicit push for member operator} 
is the base address of the
entire structure or union instance containing the member
whose address is being calculated.

\needlines{6}
\textit{For an expression such as}

\begin{lstlisting}[numbers=none]
    object.*mbr_ptr
\end{lstlisting}
\textit{where \texttt{mbr\_ptr} has some \addtoindex{pointer to member type}, a debugger should:}
\begin{enumerate}[1. ]
\item \textit{Push the value of \texttt{mbr\_ptr} onto the DWARF expression stack.}
\item \textit{Push the base address of \texttt{object} onto the DWARF expression stack.}
\item \textit{Evaluate the \DWATuselocation{} description 
given in the type of \texttt{mbr\_ptr}.}
\end{enumerate}


\section{File Type Entries}
\label{chap:filetypeentries}

\textit{Some languages, such as \addtoindex{Pascal}, 
provide a data type to represent 
files.}

A file type is represented by a debugging information entry
with 
\addtoindexx{file type entry}
the tag
\DWTAGfiletypeTARG. 
If the file type has a name,
the file type entry has a \DWATname{} attribute,
\addtoindexx{name attribute}
whose value
is a null\dash terminated string containing the type name as it
appears in the source program.

The file type entry has 
\addtoindexx{type attribute}
a \DWATtype{} attribute describing
the type of the objects contained in the file.

The file type entry also has a 
\DWATbytesize{}\addtoindexx{byte size attribute} or
\DWATbitsize{}\addtoindexx{bit size attribute} attribute, whose value 
(see Section \refersec{chap:staticanddynamicvaluesofattributes})
is the amount of storage need to hold a value of the file type.

\section{Dynamic Type Entries and Properties}

\subsection{Dynamic Type Entries}
\textit{Some languages such as 
\addtoindex{Fortran 90}, provide types whose values
may be dynamically allocated or associated with a variable
under explicit program control. However, unlike the related
pointer type in \addtoindex{C} or 
\addtoindex{C++}, the indirection involved in accessing
the value of the variable is generally implicit, that is, not
indicated as part of program source.}

A dynamic type entry is used to declare a dynamic type that is 
\doublequote{just like} another non-dynamic type without needing to
replicate the full description of that other type.

A dynamic type is represented by a debugging information entry
with the tag \DWTAGdynamictypeTARG. If a name has been given to the
dynamic type, then the dynamic type has a \DWATname{} attribute 
whose value is a null-terminated string containing the dynamic
type name as it appears in the source.
        
A dynamic type entry has a \DWATtype{} attribute whose value is a
reference to the type of the entities that are dynamically allocated.
        
A dynamic type entry also has a \DWATdatalocation, and may also
have \DWATallocated{} and/or \DWATassociated{} attributes as 
described in Section \referfol{chap:dynamictypeproperties}. 
A \DWATdatalocation, \DWATallocated{} or \DWATassociated{} attribute 
may not occur on a dynamic type entry if the same kind of attribute 
already occurs on the type referenced by the \DWATtype{} attribute.

\subsection{Dynamic Type Properties}
\label{chap:dynamictypeproperties}
\textit{
The \DWATdatalocation, \DWATallocated{} and \DWATassociated{} 
attributes described in this section can be used for any type, not
just dynamic types.}

\needlines{6}
\subsubsection{Data Location}
\label{chap:datalocation}

\textit{Some languages may represent objects using descriptors to hold
information, including a location and/or run\dash time parameters,
about the data that represents the value for that object.}

\hypertarget{chap:DWATdatalocationindirectiontoactualdata}{}
The \DWATdatalocation{} 
attribute may be used with any
\addtoindexx{data location attribute}
type that provides one or more levels of 
\addtoindexx{hidden indirection|see{data location attribute}}
hidden indirection
and/or run\dash time parameters in its representation. Its value
is a \addtoindex{location description}. 
The result of evaluating this
description yields the location of the data for an object.
When this attribute is omitted, the address of the data is
the same as the address of the object.

\needlines{5}
\textit{This location description will typically begin with
\DWOPpushobjectaddress{} 
which loads the address of the
object which can then serve as a descriptor in subsequent
calculation. For an example using 
\DWATdatalocation{} 
for a \addtoindex{Fortran 90 array}, see 
Appendix \refersec{app:fortranarrayexample}.}

\subsubsection{Allocation and Association Status}
\label{chap:allocationandassociationstatus}

\textit{Some languages, such as \addtoindex{Fortran 90},
provide types whose values
may be dynamically allocated or associated with a variable
under explicit program control.}

\hypertarget{chap:DWATallocatedallocationstatusoftypes}{}
The 
\DWATallocated{} 
attribute 
\addtoindexx{allocated attribute}
may optionally be used with any
type for which objects of the type can be explicitly allocated
and deallocated. The presence of the attribute indicates that
objects of the type are allocatable and deallocatable. The
integer value of the attribute (see below) specifies whether
an object of the type is 
currently allocated or not.

\needlines{4}
\hypertarget{chap:DWATassociatedassociationstatusoftypes}{}
The 
\DWATassociated{} attribute 
may 
\addtoindexx{associated attribute}
optionally be used with
any type for which objects of the type can be dynamically
associated with other objects. The presence of the attribute
indicates that objects of the type can be associated. The
integer value of the attribute (see below) indicates whether
an object of the type is currently associated or not.

\textit{While these attributes are defined specifically with 
\addtoindex{Fortran 90} ALLOCATABLE and POINTER types
in mind, usage is not limited
to just that language.}

The value of these attributes is determined as described in
Section \refersec{chap:staticanddynamicvaluesofattributes}.

A non\dash zero value is interpreted as allocated or associated,
and zero is interpreted as not allocated or not associated.

\textit{For \addtoindex{Fortran 90}, 
if the \DWATassociated{} 
attribute is present,
the type has the POINTER property where either the parent
variable is never associated with a dynamic object or the
implementation does not track whether the associated object
is static or dynamic. If the \DWATallocated{} attribute is
present and the \DWATassociated{} attribute is not, the type
has the ALLOCATABLE property. If both attributes are present,
then the type should be assumed to have the POINTER property
(and not ALLOCATABLE); the \DWATallocated{} attribute may then
be used to indicate that the association status of the object
resulted from execution of an ALLOCATE statement rather than
pointer assignment.}

\textit{For examples using 
\DWATallocated{} for \addtoindex{Ada} and 
\addtoindex{Fortran 90}
arrays, 
see Appendix \refersec{app:aggregateexamples}.}

\subsubsection{Array Rank}
\label{chap:DWATrank}
\addtoindexx{array!assumed-rank}
\addtoindexx{assumed-rank array|see{array, assumed-rank}}
\textit{The Fortran language supports \doublequote{assumed-rank arrays}. The
  rank (the number of dimensions) of an assumed-rank array is unknown
  at compile time. The Fortran runtime stores the rank in the array
  descriptor metadata.}

The presence of the
\hypertarget{chap:DWATrankofdynamicarray}{\DWATrankINDX}
attribute indicates that an array's rank
(number of dimensions) is dynamic, and therefore unknown at compile
time. The value of the \DWATrankNAME{} attribute is either an integer constant
or a location expression whose evaluation yields the dynamic rank.

The bounds of an array with dynamic rank are described using a
\DWTAGgenericsubrange{} entry, which  
is the dynamic rank array equivalent of
\DWTAGsubrangetype. The
difference is that a \DWTAGgenericsubrange{} entry contains generic
lower/upper bound and stride expressions that need to be evaluated for
each dimension. Before any expression contained in a
\DWTAGgenericsubrange{} can be evaluated, the dimension for which the
expression is to be evaluated needs to be pushed onto the stack. The
expression will use it to find the offset of the respective field in
the array descriptor metadata.

\textit{The Fortran compiler is free to choose any layout for the
  array descriptor. In particular, the upper and lower bounds and
  stride values do not need to be bundled into a structure or record,
  but could be laid end to end in the containing descriptor, pointed
  to by the descriptor, or even allocated independently of the
  descriptor.}

Dimensions are enumerated $0$ to $\mathit{rank}-1$ in a left-to-right
fashion.

\textit{For an example in Fortran 2008, see
  Section~\refersec{app:assumedrankexample}.}

\needlines{6}
\section{Template Alias Entries}
\label{chap:templatealiasentries}

\textit{
In \addtoindex{C++}, a template alias is a form of typedef that has template
parameters.  DWARF does not represent the template alias definition
but does represent instantiations of the alias.
}

A type named using a template alias is represented
by a debugging information entry 
\addtoindexx{template alias entry}
with the tag
\DWTAGtemplatealiasTARG. 
The template alias entry has a
\DWATname{} attribute 
\addtoindexx{name attribute}
whose value is a null\dash terminated string
containing the name of the template alias as it appears in
the source program.
The template alias entry has child entries describing the template
actual parameters (see Section \refersec{chap:templateparameters}).