&\DWATaddrbase{} \\*
&\DWATbasetypes{} \\*
&\DWATcompdir{} \\*
-\bbeb %\DWATdwoid{} \\*
-\bbeb %\DWATdwoname{} \\*
+%\DWATdwoid{} \\*
+%\DWATdwoname{} \\*
&\DWATentrypc{} \\*
&\DWATidentifiercase{} \\*
&\DWAThighpc{} \\*
&\DWATbasetypes{} \\*
&\DWATcompdir{} \\*
%\DWATdescription{} \\*
-\bbeb %&\DWATdwoid{} \\*
+%&\DWATdwoid{} \\*
&\DWATdwoname{} \\*
&\DWATentrypc{} \\*
&\DWATidentifiercase{} \\*
&\DWATtype{} \\
\hline
-\bb
\DWTAGskeletonunit
&\DWATaddrbase{} \\*
&\DWATcompdir{} \\*
&\DWATstmtlist{} \\*
&\DWATstroffsetsbase{} \\*
&\DWATuseUTFeight{}
-\eb
\\
\hline
\begin{longtable}{ll}
\textbf{Date} & \textbf{Issue Incorporated or Other Change} \\ \hline \\
\endhead
+6/19/2016 & Remove change bars, 160301.1 (unnamed namespace), 160620.1 (generic type) \\
5/19-20/2016 & 150331.1 (Add language RenderScript), 160108.1 (Unify unit headers) \\
4/15-5/2/2016 & Remove change bars, Other miscellaneous editorial work \\
3/4-7/2016 & Editorial work from 3/4/2016 editorial review \\
in the \dotdebuginfo{} section.
\item
An abbreviations table for the skeleton compilation unit,
-in the \dotdebugabbrev{} section.
+in the \dotdebugabbrev{} section
+\bb
+used by the \dotdebuginfo{} section.
+\eb
+
\item
A string table, in the \dotdebugstr{} section. The string
table is necessary only if the skeleton compilation unit
\DWFORMstrx.
\item
A string offsets table, in the \dotdebugstroffsets{}
-section. The string offsets table is necessary only if
+section
+\bb
+for strings in the \dotdebugstr{} section.
+\eb
+The string offsets table is necessary only if
the skeleton compilation unit uses the \DWFORMstrx{} form.
\end{itemize}
The attributes contained in the skeleton compilation
\item
The full compilation unit, in the \dotdebuginfodwo{} section.
\begin{itemize}
-\bbeb
\item
Attributes contained in the full compilation unit
may refer to machine addresses indirectly using the \DWFORMaddrx{}
\item
Abbreviations table(s) for the compilation unit and type
-units, in the \dotdebugabbrevdwo{} section.
+units, in the \dotdebugabbrevdwo{} section
+\bb
+used by the \dotdebuginfodwo{} section.
+\eb
\item Location lists, in the \dotdebuglocdwo{} section.
\item A string table, in the \dotdebugstrdwo{} section.
\item A string offsets table, in the \dotdebugstroffsetsdwo{}
-section.
+section
+\bb
+for the strings in the \dotdebugstrdwo{} section.
+\eb
\end{itemize}
Except where noted otherwise, all references in this document
The DWARF package file also contains two index sections that
provide a fast way to locate debug information by compilation
-unit ID
-\bbeb
-for compilation units, or by type
+unit ID for compilation units, or by type
signature for type units:
\begin{alltt}
\dotdebugcuindex
\DWUTcompileTARG~\ddag &0x01 \\
\DWUTtypeTARG~\ddag &0x02 \\
\DWUTpartialTARG~\ddag &0x03 \\
-\bb
\DWUTskeletonTARG~\ddag &0x04 \\
\DWUTsplitcompileTARG~\ddag &0x05 \\
\DWUTsplittypeTARG~\ddag &0x06 \\
\DWUTlouserTARG~\ddag &0x80 \\
\DWUThiuserTARG~\ddag &\xff
-\eb
\\
\hline
\end{longtable}
\end{centering}
-\bb
\textit{All unit headers in a compilation have the same size.
Some header types include padding bytes to achieve this.}
-\eb
-
\needlines{5}
\subsubsection{Compilation and Partial Unit Headers}
A 4-byte or 12-byte
\addtoindexx{initial length}
unsigned integer representing the length
-of the \dotdebuginfo{}
-contribution for that compilation unit,
+of the \dotdebuginfo{} contribution for that compilation unit,
not including the length field itself. In the \thirtytwobitdwarfformat,
- this is a 4-byte unsigned integer (which must be less
+this is a 4-byte unsigned integer (which must be less
than \xfffffffzero); in the \sixtyfourbitdwarfformat, this consists
of the 4-byte value \wffffffff followed by an 8-byte unsigned
integer that gives the actual length
in the \sixtyfourbitdwarfformat, this is an 8-byte unsigned length
(see Section \refersec{datarep:32bitand64bitdwarfformats}).
-\bb
\item \HFNunitpaddingONE{} (8 bytes) \\
Reserved to DWARF (must be zero).
Reserved to DWARF (must be zero). In the \thirtytwobitdwarfformat,
this is 4 bytes in length; in the \sixtyfourbitdwarfformat this
is 8 bytes in length.
-\eb
\end{enumerate}
\needlines{8}
-\bb
\subsubsection{Skeleton and Split Compilation Unit Headers}
\label{datarep:skeletonandfullcompilationunitheaders}
\begin{enumerate}[1. ]
Reserved to DWARF (must be zero). In the \thirtytwobitdwarfformat,
this is 4 bytes in length; in the \sixtyfourbitdwarfformat this
is 8 bytes in length.
-\eb
\end{enumerate}
\needlines{8}
\item \texttt{unit\_type} (\HFTubyte) \\
\addttindexx{unit\_type}
A 1-byte unsigned integer identifying this unit as a type unit.
-The value of this field is \DWUTtype{} for a
-\bb
-non-split
-\eb
-type unit
+The value of this field is \DWUTtype{} for a non-split type unit
(see Section \refersec{chap:typeunitentries})
-\bb
or \DWUTsplittype{} for a split type unit.
-\eb
\textit{This field is new in \DWARFVersionV.}
\DWTAGunspecifiedtype&0x3b \\
\DWTAGpartialunit&0x3c \\
\DWTAGimportedunit&0x3d \\
-\bb
\textit{Reserved}&0x3e\footnote{Code 0x3e is reserved to allow backward compatible support of the
DW\_TAG\_mutable\_type DIE that was defined (only) in \DWARFVersionIII.}
-\eb
\\
\DWTAGcondition&\xiiif \\
\DWTAGsharedtype&0x40 \\
\DWTAGatomictype~\ddag & 0x47 \\
\DWTAGcallsite~\ddag & 0x48 \\
\DWTAGcallsiteparameter~\ddag & 0x49 \\
-\bb
\DWTAGskeletonunit~\ddag & 0x4a
-\eb
\\
\DWTAGlouser&0x4080 \\
\DWTAGhiuser&\xffff \\
\DWATrangesbase~\ddag&0x74&
\livelinki{chap:classrangelistptr}{rangelistptr}{rangelistptr class}
\addtoindexx{ranges base!encoding} \\
-\bb
-\textit{Reserved} &0x75& \textit{Unused}
-\eb
-\\
+\textit{Reserved} &0x75& \textit{Unused} \\
\DWATdwoname~\ddag &0x76&
\livelink{chap:classstring}{string}
\addtoindexx{split DWARF object file name!encoding} \\
\DWLANGCplusplusfourteen{}~\ddag &0x0021 &0 \addtoindexx{C++14 (ISO)} \\
\DWLANGFortranzerothree{}~\ddag &0x0022 &1 \addtoindexx{Fortran:2004 (ISO)} \\
\DWLANGFortranzeroeight{}~\ddag &0x0023 &1 \addtoindexx{Fortran:2010 (ISO)} \\
-\bb
\DWLANGRenderScript{}~\ddag &0x0024 &0 \addtoindexx{RenderScript Kernel Language}
-\eb
\\
\DWLANGlouser{} &0x8000 & \\
\DWLANGhiuser{} &\xffff & \\
\textit{A type signature is computed only by a DWARF producer;
\addtoindexx{type signature!computation} a consumer need
-\bb
-only
-\eb
-compare two type signatures to check for equality.}
+only compare two type signatures to check for equality.}
\needlines{4}
The type signature for a type T0 is formed from the
as follows:
\begin{enumerate}[ a)]
\item
-\bb
-If
-\eb
-T is in the list V at some V[x], use the
+If T is in the list V at some V[x], use the
letter 'R' as the marker and use the unsigned LEB128\addtoindexx{LEB128!unsigned}
encoding of x as the attribute value.
\item
-\bb
Otherwise, append type T to the list V, then
-\eb
use the letter 'T'
as the marker, process the type T recursively by performing
Steps 2 through 7, and use the result as the attribute value.
The \texttt{debug\_info\_offset} field in the header is the
offset in the \dotdebuginfo{} section of the corresponding
compilation unit header of the skeleton \dotdebuginfo{} section
-(not the compilation unit entry). The
-\bb
-\DWATdwoname{} attribute
-\eb
-in the \dotdebuginfo{} skeleton
-\bb
-connects
-\eb
+(not the compilation unit entry). The \DWATdwoname{} attribute
+in the \dotdebuginfo{} skeleton connects
the ranges to the full compilation unit in \dotdebuginfodwo.
\itembfnl{(b) \dotdebugnames{} to \dotdebuginfo}
\itembfnl{(did) \dotdebuginfo{} to \dotdebuginfodwo}
The \DWATdwoname{}
-\bb
attribute in a skeleton unit identifies the file containing
the corresponding \texttt{.dwo} (split) data.
-\eb
\itembfnl{(do) \dotdebuginfodwo{} to \dotdebugstrdwo}
Attribute values of class string may have form
% If draft is in the document class list, pix are just suggested
% by an outline, the pic does not appear as a picture.
%
-\newcommand{\docdate}{May 20, 2016}
+\newcommand{\docdate}{June 23, 2016}
%
\usepackage{ifthen}
\newcommand{\ifthen}[2]{\ifthenelse{#1}{#2}{}}
\setcounter{secnumdepth}{5}
\uselinenos\include{introduction} %\emptypage
-\uselinenos\include{generaldescription} \emptypage
+\uselinenos\include{generaldescription} %\emptypage
\uselinenos\include{programscope} %\emptypage
\uselinenos\include{dataobject} \emptypage
\uselinenos\include{typeentries} \emptypage
\newcommand{\MDfive}{\livelink{def:MDfive}{MD5}}
\newcommand{\COMDAT}{\addtoindex{COMDAT}}
\newcommand{\autoreturntype}{\texttt{auto} return type\index{auto return type@\texttt{auto} return type}}
-\newcommand{\specialaddresstype}{\livelink{chap:specialaddresstype}{special address type}}
+\newcommand{\generictype}{\livelink{chap:generictype}{generic type}}
\newcommand{\splitDWARFobjectfile}{\addtoindex{split DWARF object file}}
\newcommand{\compunitset}{\addtoindex{compilation unit set}}
\newcommand{\typeunitset}{\addtoindex{type unit set}}
}
\needlines{6}
-\bb
\descriptionitemnl{\DWOPentryvalue{} 1 \DWOPregfive{} \DWOPplusuconst{} 16 }
The address of the memory location is calculated by adding 16 to the value
contained in register 5 upon entering the current subprogram.
\textit{Note that unlike the previous \DWOPentryvalue{} examples, this one does not end
with \DWOPstackvalue.{}}
-\eb
\end{description}
\end{lstlisting}
\textit{
-\bb
Recall that \texttt{desc\textless 1\textgreater}
indicates the 1\dash dimensional version of \texttt{desc}.
-\eb
}
%\newpage
\DWTAGrvaluereferencetype,
\DWTAGsettype,
\DWTAGsharedtype,
-\bb
\DWTAGskeletonunit,
-\eb
\DWTAGstringtype,
\DWTAGstructuretype,
\DWTAGsubprogram,
&\livelinki{chap:DWATdiscrvaluediscriminantvalue}
{Discriminant value}
{discriminant value} \\
-\bbeb
\DWATdwonameTARG
&\livelinki{chap:DWATdwonameforunit}
{Name of split DWARF object file}
Each element of the stack has a type and a value, and can represent
a value of any supported base type of the target machine. Instead of
a base type, elements can have a
-\definitionx{special address type}\livetarg{chap:specialaddresstype}{},
+\definitionx{generic type}\livetarg{chap:generictype}{},
which is an integral type that has the
\addtoindex{size of an address} on the target machine and
unspecified signedness. The value on the top of the stack after
value of the array bound, the length of a dynamic string,
the desired value itself, and so on).
+\textit{The
+\bb
+\generictype{} is the same as the unspecified type used for stack operations
+defined in \DWARFVersionIV{} and before.
+\eb
+}
\needlines{4}
\subsubsection{Literal Encodings}
stack.
\addtoindexx{DWARF expression!stack operations}
Operations other than \DWOPconsttype{} push a value with the
-\specialaddresstype, and if the value of a constant in one of these
+\generictype, and if the value of a constant in one of these
operations is larger than can be stored in a single stack element,
the value is truncated to the element size and the low-order bits
are pushed on the stack.
\DWOPregvaltype{} pushes the contents
of the register together with the given base type, while the other operations
push the result of adding the contents of a register to a given
-signed offset together with the \specialaddresstype.
+signed offset together with the \generictype.
\needlines{8}
\begin{enumerate}[1. ]
The \DWOPderefNAME{} operation pops the top stack entry and
treats it as an address. The popped value must have an integral type.
The value retrieved from that address is pushed,
-and has the \specialaddresstype{}.
+and has the \generictype{}.
The size of the data retrieved from the
\addtoindexi{dereferenced}{address!dereference operator}
address is the \addtoindex{size of an address} on the target machine.
operation: it pops the top stack entry and treats it as an
address. The popped value must have an integral type.
The value retrieved from that address is pushed,
-and has the \specialaddresstype{}.
+and has the \generictype{}.
In the \DWOPderefsizeNAME{} operation, however, the size in bytes
of the data retrieved from the dereferenced address is
specified by the single operand. This operand is a 1-byte
unsigned integral constant whose value may not be larger
-than the size of the \specialaddresstype. The data
+than the size of the \generictype. The data
retrieved is zero extended to the size of an address on the
target machine before being pushed onto the expression stack.
The top two stack elements are popped,
and a data item is retrieved through an implementation-defined
address calculation and pushed as the new stack top together with the
-\specialaddresstype{} identifier.
+\generictype{} identifier.
The size of the data retrieved from the
\addtoindexi{dereferenced}{address!dereference operator}
-address is the size of the \specialaddresstype.
+address is the size of the \generictype.
\needlines{4}
\itembfnl{\DWOPxderefsizeTARG}
than the \addtoindex{size of an address} on the target machine. The data
retrieved is zero extended to the \addtoindex{size of an address} on the
target machine before being pushed onto the expression stack together
-with the \specialaddresstype{} identifier.
+with the \generictype{} identifier.
\itembfnl{\DWOPxdereftypeTARG}
The \DWOPxdereftypeNAME{} operation behaves like the \DWOPxderefsize{}
value into an address in the
\addtoindex{thread-local storage}
for a thread, and pushes the address
-onto the stack together with the \specialaddresstype{} identifier.
+onto the stack together with the \generictype{} identifier.
The meaning of the value on the top of the stack prior to this
operation is defined by the run-time environment. If the run-time
environment supports multiple thread-local storage
The following provide arithmetic and logical operations.
Operands of an operation with two operands
must have the same type,
-either the same base type or both the \specialaddresstype.
+either the same base type or
+\bbeb
+the \generictype.
The result of the operation which is pushed back has the same type
as the type of the operand(s).
-If the type of the operands is the \specialaddresstype,
+If the type of the operands is the \generictype,
except as otherwise specified, the arithmetic operations
perform addressing arithmetic, that is, unsigned arithmetic that is performed
modulo one plus the largest representable address (for example, 0x100000000
Operations other than \DWOPabs{},
\DWOPdiv{}, \DWOPminus{}, \DWOPmul{}, \DWOPneg{} and \DWOPplus{}
require integral types of the operand (either integral base type
-or the \specialaddresstype). Operations do not cause an exception
+or the \generictype). Operations do not cause an exception
on overflow.
\needlines{4}
The six relational operators each:
\begin{itemize}
\item pop the top two stack values, which have the same type,
-either the same base type or both the \specialaddresstype,
+either the same base type or
+\bbeb
+the \generictype,
\item compare the operands:
\linebreak
\item push the constant value 1 onto the stack
if the result of the operation is true or the
constant value 0 if the result of the operation is false.
-The pushed value has the \specialaddresstype.
+The pushed value has the \generictype.
\end{itemize}
-If the operands have the \specialaddresstype, the comparisons
+If the operands have the \generictype, the comparisons
are performed as signed operations.
\needlines{6}
different type, then pushes the result. It takes one operand, which is an
unsigned LEB128 integer that represents the offset of a debugging
information entry in the current compilation unit, or value 0 which
-represents the \specialaddresstype. If the operand is non-zero, the
+represents the \generictype. If the operand is non-zero, the
referenced entry must be a \DWTAGbasetype{} entry that provides the type
to which the value is converted.
the bits in its value as a value of a different type, then pushes the
result. It takes one operand, which is an unsigned LEB128 integer that
represents the offset of a debugging information entry in the current
-compilation unit, or value 0 which represents the \specialaddresstype.
+compilation unit, or value 0 which represents the \generictype.
If the operand is non-zero, the referenced entry must be a
\DWTAGbasetype{} entry that provides the type to which the value is converted.
The type of the operand and result type should have the same size in bits.
\itembfnl{\DWOPentryvalueNAME}
The \DWOPentryvalueTARG{} operation pushes
-\bb
the value that the described location held
-\eb
upon entering the current subprogram. It has two operands: an
unsigned LEB128\addtoindexx{LEB128!unsigned} length, followed by
a block containing a DWARF expression or a register location description
the subprogram, and then continue; when evaluating \DWOPentryvalueNAME{},
the consumer would use these recorded values rather than the current
values. Or, when evaluating \DWOPentryvalueNAME{}, the consumer could
-\bb
-virtually unwind
-\eb
-using the Call Frame Information
+virtually unwind using the Call Frame Information
(see Section \refersec{chap:callframeinformation})
to recover register values that might have been clobbered since the
subprogram entry point.}
\needlines{5}
\subsubsection{Location Lists in Split Object Files}
\label{chap:locationlistsinsplitobjectfiles}
+\bb
+\textit{Location lists in split units use a format that
+eliminates the need for relocations in the containing file.}
+\eb
+
In a \splitDWARFobjectfile{} (see
Section \refersec{datarep:splitdwarfobjectfiles}),
location lists are contained in the \dotdebuglocdwo{} section.
rather than using common practice or convention as an implicit
understanding between producer and consumer. For example, where
other debugging formats assume that a debugger knows how to
-\bb
-virtually
-\eb
-unwind the stack, moving from one stack frame to the next using
+virtually unwind the stack, moving from one stack frame to the next using
implicit knowledge about the architecture or operating system,
DWARF makes this explicit in the Call Frame Information description.
fashion, informative text will suggest but not require this design.
\subsection{Permissive Rather Than Prescriptive}
-\bb
The DWARF Standard specifies the meaning of DWARF descriptions. It does not
specify in detail what a particular producer should generate for any source to
object conversion. One producer may generate a more complete description
valid DWARF descriptions, while a consumer using the former would be able
to provide more accurate values for the variable while executing in that
range than a consumer using the latter.
-\eb
\subsection{Vendor Extensibility}
This document does not attempt to cover all interesting
string is padded with null characters to a multiple of
four bytes in length.
-\textit{The
-\bb
-presence of an unrecognised augmentation string may make it impossible
-for a consumer to process data in the \dotdebugnames{} section.
-\eb}
+\textit{The presence of an unrecognised augmentation string may make it impossible
+for a consumer to process data in the \dotdebugnames{} section.}
\end{enumerate}
\textit{To be able to view or modify an activation that is not
on the top of the call frame stack, the debugger must
-\bb
-virtually unwind
-\eb
-the stack of activations until
-it finds the activation of interest. A debugger
-\bb
-virtually
-\eb
-unwinds
+virtually unwind the stack of activations until
+it finds the activation of interest. A debugger virtually unwinds
a stack in steps. Starting with the current activation it
virtually restores any registers that were preserved by the
current activation and computes the predecessor\textquoteright{s} CFA and
of the target process is unchanged.}
\needlines{4}
-\textit{The
-\bb
-virtual unwind
-\eb
+\textit{The virtual unwind
operation needs to know where registers are
saved and how to compute the predecessor\textquoteright{s} CFA and code
location. When considering an architecture-independent way
\needlines{5}
\textit{The augmentation string allows users to indicate that there
is additional target\dash specific information in the CIE or FDE
-which is needed to
-\bb
-virtually
-\eb
+which is needed to virtually
unwind a stack frame. For example, this
might be information about dynamically allocated data which
needs to be freed on exit from the routine.}
\label{chap:callframeinstructionusage}
\textit{To determine the virtual unwind rule set for a given location
-(L1), one searches through the FDE headers looking at the
-\addttindex{initial\_location} and \addttindex{address\_range} values to see if L1 is
+(L1),
+\bb
+search
+\eb
+through the FDE headers looking at the
+\HFNinitiallocation{} and \HFNaddressrange{} values to see if L1 is
contained in the FDE. If so, then:}
\begin{enumerate}[1. ]
\item \textit{Initialize a register set by reading the
-\texttt{initial\_instructions} field of the associated CIE.}
+\HFNinitialinstructions{} field of the associated CIE.
+\bb
+Set L2 to the value of the \HFNinitiallocation{} field from the FDE header.
+\eb}
-\item \textit{Read and process the FDE\textquoteright s instruction
+
+\item \textit{Read and process the FDE's instruction
sequence until a \DWCFAadvanceloc,
\DWCFAsetloc, or the
end of the instruction stream is encountered.}
\label{chap:callframecallingaddress}
\textit{When
-\bb
-virtually
-\eb
-unwinding frames, consumers frequently wish to obtain the
-address of the instruction which called a subroutine. This
+virtually unwinding frames, consumers frequently wish to obtain
+the address of the instruction which called a subroutine. This
information is not always provided. Typically, however,
one of the registers in the virtual unwind table is the
Return Address.}
or past the end of the calling
subroutine. If a consumer were to assume that it was in the
same context as the calling address, the
-\bb
-virtual
-\eb
-unwind might fail.}
+virtual unwind might fail.}
\needlines{5}
\textit{For architectures with constant-length instructions where
\DWLANGPascaleightythreeTARG & ISO Pascal:1983 \addtoindexx{Pascal:1983 (ISO)} \\
\DWLANGPLITARG{}~\dag & ANSI PL/I:1976 \addtoindexx{PL/I:1976 (ANSI)} \\
\DWLANGPythonTARG{}~\dag & \addtoindex{Python} \\
-\bb
\DWLANGRenderScriptTARG~\dag & \addtoindex{RenderScript Kernal Language}
-\eb
\\
\DWLANGRustTARG{}~\dag & \addtoindex{Rust} \\
\DWLANGSwiftTARG{}
Section \refersec{datarep:splitdwarfobjectfiles}), the
compilation unit in the \dotdebuginfo{} section is a "skeleton"
compilation unit with the tag
-\bb
\DWTAGskeletonunitTARG, which contains a
-\DWATdwoname{} attribute
-\eb
-as well as a subset of the
+\DWATdwoname{} attribute as well as a subset of the
attributes of a full or partial compilation unit. In general,
it contains those attributes that are necessary for the consumer
to locate the object file where the split full compilation unit
A skeleton compilation unit has no children.
-A skeleton compilation unit has
-\bb
-a \DWATdwoname{} attribute:
-\eb
+A skeleton compilation unit has a \DWATdwoname{} attribute:
\begin{enumerate}[1. ]
see below) of the object file that contains the full
compilation unit.
-\bb
The value in the \HFNdwoid{} field of the unit header for
this unit is the same as the value in the \HFNdwoid{} field
of the unit header of the corresponding full compilation
kinds of mismatched files and for looking up a full
split unit in a DWARF package file
(see Section \refersec{datarep:dwarfpackagefiles}).}
-\eb
\end{enumerate}
The attributes provided by the skeleton compilation
unit entry do not need to be repeated in the full compilation
unit entry.
-\bbeb
\textit{The \DWATaddrbase{}, \DWATrangesbase{} and
\DWATstroffsetsbase{} attributes provide context that may be
being physically separate.
A split full compilation unit
-\bb
may have the following attributes,
which are the same as for conventional compilation unit entries
except as noted:
-\eb
\begin{enumerate}[1. ]
\item A \DWATname{} attribute.
\item A \DWATlanguage{} attribute.
be represented by a namespace entry with no name attribute in
the original namespace declaration entry (and therefore no name
attribute in any namespace extension entry of this namespace).
+\bb
+C++ states that declarations in the unnamed namespace are
+implicitly available in the containing scope; a producer
+should make this effect explicit with the \DWATexportsymbols{}
+attribute, or by using a \DWTAGimportedmodule{} that is a
+sibling of the namespace entry and references it.
+\eb
}
\textit{A compiler emitting namespace information may choose to
registers and memory locations might have been modified. In order to
recover the values that existed at the point of the call (to allow
evaluation of the DWARF expression for the actual parameter), a debugger
-may
-\bb
-virtually unwind
-\eb
-the subprogram activation
+may virtually unwind the subprogram activation
(see Section \refersec{chap:callframeinformation}). Any
register or memory location that cannot be recovered is referred to as
"clobbered by the call."}
transfers control to the start of some subprogram, but
there is no call site location address to preserve
(and thus none is available using the
-\bb
-virtual
-\eb
-unwind information).
+virtual unwind information).
\item
A \textit{tail recursion call} is a call
\textit{The expression should not use registers or memory
locations that might be clobbered by the call, as it might be evaluated after
-\bb
-virtually
-\eb
-unwinding from the called function back to the caller. If it is not
+virtually unwinding from the called function back to the caller. If it is not
possible to avoid registers or memory locations that might be clobbered by
the call in the expression, then the \DWATcallvalueNAME{} attribute should
not be provided.}
\DWATcalldatavalueNAME{} attribute describes the value in that location.
The expression should not use registers or memory
locations that might be clobbered by the call, as it might be evaluated after
-\bb
-virtually
-\eb
-unwinding from the called function back to the caller.
+virtually unwinding from the called function back to the caller.
\needlines{4}
Each call site parameter entry may also have a
\DWATaddrbase{},
\DWATcompdir{},
\DWATdwoname{},
-\bbeb %\DWATdwoid{},
+%\DWATdwoid{},
\DWAThighpc{},
\DWATlowpc{},
\DWATranges{},
All other attributes of the compilation unit DIE are moved to
the full DIE in the \dotdebuginfodwo{} section.
-\bb
The \HFNdwoid{} field is present in headers of the skeleton DIE
and the header of the full DIE, so that a consumer
can verify a match.
-\eb
\needlines{4}
Relocations are neither necessary nor useful in
\hline
\DWATcompdir & \chkmk & & \chkmk & & \\
\hline
-\bbeb %\DWATdwoid & & & \chkmk & \chkmk & \\
+%\DWATdwoid & & & \chkmk & \chkmk & \\
%\hline
\DWATdwoname & & & \chkmk & & \\
\hline
contains the full debug information; that file is normally
expected to be in the same directory as the object file itself.
-The
-\bb
-\HFNdwoid{} field in the header of the skeleton unit provides
+The \HFNdwoid{} field in the header of the skeleton unit provides
an ID or key for the debug information contained in the
DWARF object file. This ID serves
-\eb
two purposes: it can be used to verify that the debug information
in the \splitDWARFobjectfile{} matches the information in the object
file, and it can be used to find the debug information in a DWARF
DWARF Git Projects / dwarf-doc.git / commitdiff