Incorporate changes as of the May 17 meeting. The corresponding
[dwarf-doc.git] / dwarf5 / latexdoc / datarepresentation.tex
index 296c5c3..55958f6 100644 (file)
@@ -5,7 +5,6 @@ This section describes the binary representation of the
 debugging information entry itself, of the attribute types
 and of other fundamental elements described above.
 
-
 \section{Vendor Extensibility}
 \label{datarep:vendorextensibility}
 \addtoindexx{vendor extensibility}
@@ -19,22 +18,23 @@ special labels are reserved for tag names, attribute names,
 base type encodings, location operations, language names,
 calling conventions and call frame instructions.
 
-The labels denoting the beginning and end of the reserved
-\hypertarget{chap:DWXXXlohiuser}{}
-value range for vendor specific extensions consist of the
+The labels denoting the beginning and end of the 
+\hypertarget{chap:DWXXXlohiuser}{reserved value range}
+for vendor specific extensions consist of the
 appropriate prefix 
-(\DWATlouserMARK{}\DWAThiuserMARK{}    DW\_AT,
-\DWATElouserMARK{}\DWATEhiuserMARK{}   DW\_ATE, 
-\DWCClouserMARK{}\DWCChiuserMARK{}     DW\_CC,
-\DWCFAlouserMARK{}\DWCFAhiuserMARK{}   DW\_CFA 
-\DWENDlouserMARK{}\DWENDhiuserMARK{}   DW\_END, 
-\DWLANGlouserMARK{}\DWLANGhiuserMARK{}  DW\_LANG, 
-\DWLNElouserMARK{}\DWLNEhiuserMARK{}   DW\_LNE, 
-\DWMACROlouserMARK{}\DWMACROhiuserMARK{}DW\_MACRO,
-\DWOPlouserMARK{}\DWOPhiuserMARK{}     DW\_OP or
-\DWTAGlouserMARK{}\DWTAGhiuserMARK{}   DW\_TAG, 
-respectively) followed by
-\_lo\_user or \_hi\_user. 
+(\DWATlouserMARK{}\DWAThiuserMARK{}DW\_AT, 
+\DWATElouserMARK{}\DWATEhiuserMARK{}DW\_ATE, 
+\DWCClouserMARK{}\DWCChiuserMARK{}DW\_CC, 
+\DWCFAlouserMARK{}\DWCFAhiuserMARK{}DW\_CFA, 
+\DWENDlouserMARK{}\DWENDhiuserMARK{}DW\_END, 
+\DWIDXlouserMARK{}\DWIDXhiuserMARK{}DW\_IDX, 
+\DWLANGlouserMARK{}\DWLANGhiuserMARK{}DW\_LANG, 
+\DWLNCTlouserMARK{}\DWLNCThiuserMARK{}DW\_LNCT, 
+\DWLNElouserMARK{}\DWLNEhiuserMARK{}DW\_LNE, 
+\DWMACROlouserMARK{}\DWMACROhiuserMARK{}DW\_MACRO, 
+\DWOPlouserMARK{}\DWOPhiuserMARK{}DW\_OP or 
+\DWTAGlouserMARK{}\DWTAGhiuserMARK{}DW\_TAG) 
+followed by \_lo\_user or \_hi\_user. 
 Values in the  range between \textit{prefix}\_lo\_user 
 and \textit{prefix}\_hi\_user inclusive,
 are reserved for vendor specific extensions. Vendors may
@@ -42,8 +42,8 @@ use values in this range without conflicting with current or
 future system\dash defined values. All other values are reserved
 for use by the system.
 
-\textit{For example, for DIE tags, the special
-labels are \DWTAGlouserNAME{} and \DWTAGhiuserNAME.}
+\textit{For example, for debugging information entry
+tags, the special labels are \DWTAGlouserNAME{} and \DWTAGhiuserNAME.}
 
 \textit{There may also be codes for vendor specific extensions
 between the number of standard line number opcodes and
@@ -51,8 +51,7 @@ the first special line number opcode. However, since the
 number of standard opcodes varies with the DWARF version,
 the range for extensions is also version dependent. Thus,
 \DWLNSlouserTARG{} and 
-\DWLNShiuserTARG{} symbols are not defined.
-}
+\DWLNShiuserTARG{} symbols are not defined.}
 
 Vendor defined tags, attributes, base type encodings, location
 atoms, language names, line number actions, calling conventions
@@ -64,20 +63,20 @@ other vendors.
 
 To ensure that extensions added by one vendor may be safely
 ignored by consumers that do not understand those extensions,
-the following rules should be followed:
+the following rules must be followed:
 \begin{enumerate}[1. ]
 
-\item New attributes should be added in such a way that a
+\item New attributes are added in such a way that a
 debugger may recognize the format of a new attribute value
 without knowing the content of that attribute value.
 
-\item The semantics of any new attributes should not alter
+\item The semantics of any new attributes do not alter
 the semantics of previously existing attributes.
 
-\item The semantics of any new tags should not conflict with
+\item The semantics of any new tags do not conflict with
 the semantics of previously existing tags.
 
-\item Do not add any new forms of attribute value.
+\item New forms of attribute value are not added.
 
 \end{enumerate}
 
@@ -95,8 +94,8 @@ a convenience for consumers of DWARF information, the value
 forms, base type encodings, location operations, languages,
 line number program opcodes, macro information entries and tag
 names to represent an error condition or unknown value. DWARF
-does not specify names for these reserved values, since they
-do not represent valid encodings for the given type and should
+does not specify names for these reserved values, because they
+do not represent valid encodings for the given type and do
 not appear in DWARF debugging information.
 
 
@@ -120,18 +119,17 @@ In an \addtoindex{initial length} field, the values \wfffffffzero through
 \wffffffff are reserved by DWARF to indicate some form of
 extension relative to \DWARFVersionII; such values must not
 be interpreted as a length field. The use of one such value,
-\xffffffff, is defined below 
-(see Section \refersec{datarep:32bitand64bitdwarfformats}); 
+\xffffffff, is defined in
+Section \refersec{datarep:32bitand64bitdwarfformats}); 
 the use of
 the other values is reserved for possible future extensions.
 
 
-
 \section{Relocatable, Split, Executable, Shared and Package Object Files} 
 \label{datarep:executableobjectsandsharedobjects}
 
-\subsection{Relocatable Objects}
-\label{data:relocatableobjects}
+\subsection{Relocatable Object Files}
+\label{datarep:relocatableobjectfiles}
 A DWARF producer (for example, a compiler) typically generates its
 debugging information as part of a relocatable object file.
 Relocatable object files are then combined by a linker to form an
@@ -165,21 +163,20 @@ These attributes represent locations
 within the virtual address space of the program, and require
 relocation.
 
+\item A DWARF expression may contain a \DWOPaddr{} (see Section 
+\refersec{chap:literalencodings}) which contains a location within 
+the virtual address space of the program, and require relocation.
+
+\needlines{4}
 \item Debugging information entries may have attributes with the form
 \DWFORMsecoffset{} (see Section \refersec{datarep:attributeencodings}). 
 These attributes refer to
 debugging information in other debugging information sections within
 the object file, and must be relocated during the linking process.
-Exception: attributes whose values are relative to a base offset given
-by \DWATrangesbase{} do not need relocation.
-
-\item Debugging information entries may have attributes with the form
-\DWFORMrefone, \DWFORMreftwo, \DWFORMreffour, \DWFORMrefeight, or
-\DWFORMrefudata{} (see Section \refersec{datarep:attributeencodings}). 
-These attributes refer to other
-debugging information entries within the same compilation unit, and
-are relative to the beginning of the current compilation unit. These
-values do not need relocation.
+\par
+However, if a \DWATrangesbase{} attribute is present, the offset in
+a \DWATranges{} attribute (which uses form \DWFORMsecoffset) is
+relative to the given base offset--no relocation is involved.
 
 \item Debugging information entries may have attributes with the form
 \DWFORMrefaddr{} (see Section \refersec{datarep:attributeencodings}). 
@@ -193,7 +190,8 @@ relocation.
 These attributes refer to strings in
 the \dotdebugstr{} section. These values require relocation.
 
-\item Entries in the \dotdebugloc{}, \dotdebugranges{}, and \dotdebugaranges{}
+\item Entries in the \dotdebugaddr, \dotdebugloc{}, \dotdebugranges{} 
+and \dotdebugaranges{}
 sections contain references to locations within the virtual address
 space of the program, and require relocation.
 
@@ -201,19 +199,47 @@ space of the program, and require relocation.
 opcode is a reference to a location within the virtual address space
 of the program, and requires relocation.
 
- The \dotdebugstroffsets{} section contains a list of string offsets,
+\item The \dotdebugstroffsets{} section contains a list of string offsets,
 each of which is an offset of a string in the \dotdebugstr{} section. Each
 of these offsets requires relocation. Depending on the implementation,
 these relocations may be implicit (that is, the producer may not need to
 emit any explicit relocation information for these offsets).
+
+\item The \HFNdebuginfooffset{} field in the \dotdebugaranges{} header and 
+the list of compilation units following the \dotdebugnames{} header contain 
+references to the \dotdebuginfo{} section.  These references require relocation 
+so that after linking they refer to the correct contribution in the combined 
+\dotdebuginfo{} section in the executable file.
+
+\item Frame descriptor entries in the \dotdebugframe{} section 
+(see Section \refersec{chap:structureofcallframeinformation}) contain an 
+\HFNinitiallocation{} field value within the virtual address 
+space of the program and require relocation. 
+
 \end{itemize}
 
-\subsection{Split DWARF Objects}
-\label{datarep:splitdwarfobjects}
+\needlines{4}
+\textit{Note that operands of classes 
+\CLASSconstant{} and 
+\CLASSflag{} do not require relocation. Attribute operands that use 
+forms \DWFORMstring{},
+\DWFORMrefone, \DWFORMreftwo, \DWFORMreffour, \DWFORMrefeight, or
+\DWFORMrefudata{} also do not need relocation.}
+
+\subsection{Split DWARF Object Files}
+\label{datarep:splitdwarfobjectfiles}
+\addtoindexx{split DWARF object file}
 A DWARF producer may partition the debugging
 information such that the majority of the debugging
 information can remain in individual object files without
-being processed by the linker. The first partition contains
+being processed by the linker. 
+
+\textit{This reduces link time by reducing the amount of information
+the linker must process.}
+
+\needlines{6}
+\subsubsection{First Partition (with Skeleton Unit)}
+The first partition contains
 debugging information that must still be processed by the linker,
 and includes the following:
 \begin{itemize}
@@ -249,24 +275,35 @@ section. 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
-unit can be used by a DWARF consumer to find the object file
-or DWARF object file that contains the second partition.
+unit can be used by a DWARF consumer to find the 
+DWARF object file that contains the second partition.
 
+\subsubsection{Second Partition (Unlinked or in a \texttt{.dwo} File)}
 The second partition contains the debugging information that
 does not need to be processed by the linker. These sections
 may be left in the object files and ignored by the linker
-(that is, not combined and copied to the executable object), or
+(that is, not combined and copied to the executable object file), or
 they may be placed by the producer in a separate DWARF object
 file. This partition includes the following:
 \begin{itemize}
 \item
 The full compilation unit, in the \dotdebuginfodwo{} section.
-Attributes in debugging information entries may refer to
-machine addresses indirectly using the \DWFORMaddrx{} form,
-and location expressions may do so using the \DWOPaddrx{} and
-\DWOPconstx{} forms. Attributes may refer to range table
-entries with an offset relative to a base offset in the
-range table for the compilation unit.
+\begin{itemize}
+\bbeb
+\item
+Attributes contained in the full compilation unit
+may refer to machine addresses indirectly using the \DWFORMaddrx{} 
+form, which accesses the table of addresses specified by the
+\DWATaddrbase{} attribute in the associated skeleton unit.
+Location descriptions may similarly do so using the \DWOPaddrx{} and
+\DWOPconstx{} operations. 
+
+\item
+\DWATranges{} attributes contained in the full compilation unit
+may refer to range table entries with a \DWFORMsecoffset{} offset 
+relative to the base offset specified by the \DWATrangesbase{}
+attribute in the associated skeleton unit.
+\end{itemize}
 
 \item Separate type units, in the \dotdebuginfodwo{} section.
 
@@ -293,31 +330,56 @@ section.
 
 Except where noted otherwise, all references in this document
 to a debugging information section (for example, \dotdebuginfo),
-applies also to the corresponding split DWARF section (for example,
+apply also to the corresponding split DWARF section (for example,
 \dotdebuginfodwo).
 
+\needlines{4}
+Split DWARF object files do not get linked with any other files,
+therefore references between sections must not make use of
+normal object file relocation information. As a result, symbolic
+references within or between sections are not possible.
+
 \subsection{Executable Objects}
 \label{chap:executableobjects}
 The relocated addresses in the debugging information for an
 executable object are virtual addresses.
 
-\subsection{Shared Objects}
-\label{datarep:sharedobjects}
+The sections containing the debugging information are typically
+not loaded as part of the memory image of the program (in ELF
+terminology, the sections are not "allocatable" and are not part
+of a loadable segment). Therefore, the debugging information
+sections described in this document are typically linked as if
+they were each to be loaded at virtual address 0, and references
+within the debugging information always implicitly indicate which
+section a particular offset refers to. (For example, a reference
+of form \DWFORMsecoffset{} may refer to one of several sections,
+depending on the class allowed by a particular attribute of a
+debugging information entry, as shown in 
+Table \refersec{tab:attributeencodings}.)
+
+\needlines{6}
+\subsection{Shared Object Files}
+\label{datarep:sharedobjectfiles}
 The relocated
-addresses in the debugging information for a shared object
+addresses in the debugging information for a shared object file
 are offsets relative to the start of the lowest region of
-memory loaded from that shared object.
+memory loaded from that shared object file.
 
 \needlines{4}
 \textit{This requirement makes the debugging information for
-shared objects position independent.  Virtual addresses in a
-shared object may be calculated by adding the offset to the
-base address at which the object was attached. This offset
+shared object files position independent.  Virtual addresses in a
+shared object file may be calculated by adding the offset to the
+base address at which the object file was attached. This offset
 is available in the run\dash time linker\textquoteright s data structures.}
 
+As with executable objects, the sections containing debugging
+information are typically not loaded as part of the memory image
+of the shared object, and are typically linked as if they were
+each to be loaded at virtual address 0.
+
 \subsection{DWARF Package Files}
 \label{datarep:dwarfpackagefiles}
-\textit{Using split DWARF objects allows the developer to compile, 
+\textit{Using \splitDWARFobjectfile{s} allows the developer to compile, 
 link, and debug an application quickly with less link-time overhead,
 but a more convenient format is needed for saving the debug
 information for later debugging of a deployed application. A
@@ -329,15 +391,16 @@ produced during the compilation of an application.}
 application, and is given the same name with a \doublequote{\texttt{.dwp}}
 extension.\addtoindexx{\texttt{.dwp} file extension}}
 
+\needlines{4}
 A DWARF package file is itself an object file, using the
 \addtoindexx{package files}
 \addtoindexx{DWARF package files}
-same object file format (including byte order) as the
+same object file format (including \byteorder) as the
 corresponding application binary. It consists only of a file
-header, section table, a number of DWARF debug information
+header, section table, a number of DWARF debug information
 sections, and two index sections.
 
-\needlines{5}
+\needlines{10}
 Each DWARF package file contains no more than one of each of the
 following sections, copied from a set of object or DWARF object
 files, and combined, section by section:
@@ -354,14 +417,16 @@ files, and combined, section by section:
 The string table section in \dotdebugstrdwo{} contains all the
 strings referenced from DWARF attributes using the form
 \DWFORMstrx. Any attribute in a compilation unit or a type
-unit using this form will refer to an entry in that unit's
+unit using this form refers to an entry in that unit's
 contribution to the \dotdebugstroffsetsdwo{} section, which in turn
-will provide the offset of a string in the \dotdebugstrdwo{}
+provides the offset of a string in the \dotdebugstrdwo{}
 section.
 
 The DWARF package file also contains two index sections that
 provide a fast way to locate debug information by compilation
-unit signature (\DWATdwoid) for compilation units, or by type
+unit ID 
+\bbeb 
+for compilation units, or by type
 signature for type units:
 \begin{alltt}
     \dotdebugcuindex
@@ -370,11 +435,11 @@ signature for type units:
 
 \subsubsection{The Compilation Unit (CU) Index Section}
 The \dotdebugcuindex{} section is a hashed lookup table that maps a
-compilation unit signature to a set of contributions in the
+compilation unit ID to a set of contributions in the
 various debug information sections. Each contribution is stored
 as an offset within its corresponding section and a size.
 
-Each compilation unit set may contain contributions from the
+Each \compunitset{} may contain contributions from the
 following sections:
 \begin{alltt}
     \dotdebuginfodwo{} (required)
@@ -385,7 +450,7 @@ following sections:
     \dotdebugmacrodwo
 \end{alltt}
 
-\textit{Note that a set is not able to represent \dotdebugmacinfo{}
+\textit{Note that a \compunitset{} is not able to represent \dotdebugmacinfo{}
 information from \DWARFVersionIV{} or earlier formats.}
 
 \subsubsection{The Type Unit (TU) Index Section}
@@ -394,7 +459,7 @@ type signature to a set of offsets into the various debug
 information sections. Each contribution is stored as an offset
 within its corresponding section and a size.
 
-Each type unit set may contain contributions from the following
+Each \typeunitset{} may contain contributions from the following
 sections:
 \begin{alltt}
     \dotdebuginfodwo{} (required) 
@@ -404,32 +469,30 @@ sections:
 \end{alltt}
 
 \subsubsection{Format of the CU and TU Index Sections}
-Both index sections have the same format, and serve to map a
-64-bit signature to a set of contributions to the debug sections.
-Each section begins with a header, followed by a hash table of
+Both index sections have the same format, and serve to map an
+8-byte signature to a set of contributions to the debug sections.
+Each index section begins with a header, followed by a hash table of
 signatures, a parallel table of indexes, a table of offsets, and
 a table of sizes. The index sections are aligned at 8-byte
-boundaries in the file.
+boundaries in the DWARF package file.
 
 \needlines{6}
 The index section header contains the following fields:
 \begin{enumerate}[1. ]
 \item \texttt{version} (\HFTuhalf) \\
-A version number
+A version number.
 \addtoindexx{version number!CU index information} 
 \addtoindexx{version number!TU index information}
-(see Appendix \refersec{app:dwarfsectionversionnumbersinformative}). 
 This number is specific to the CU and TU index information
 and is independent of the DWARF version number.
 
 The version number is \versiondotdebugcuindex.
 
 \item \textit{padding} (\HFTuhalf) \\
-Reserved to DWARF.
-
-\item \texttt{column\_count} (\HFTuword) \\
-The number of columns in the table of section counts that follows.
-For brevity, the contents of this field is referred to as $C$ below.
+Reserved to DWARF (must be zero).
+\item \texttt{section\_count} (\HFTuword) \\
+The number of entries in the table of section counts that follows.
+For brevity, the contents of this field is referred to as $N$ below.
 
 \item \texttt{unit\_count} (\HFTuword) \\
 The number of compilation units or type units in the index.
@@ -447,13 +510,13 @@ The size of the hash table, $S$, must be $2^k$ such that:
 \hspace{0.3cm}$2^k\ \ >\ \ 3*U/2$
 
 The hash table begins at offset 16 in the section, and consists
-of an array of $M$ 64-bit slots. Each slot contains a 64-bit
+of an array of $S$ 8-byte slots. Each slot contains a 64-bit
 signature.
-% (using the byte order of the application binary).
+% (using the \byteorder{} of the application binary).
 
 The parallel table of indices begins immediately after the hash table 
 (at offset \mbox{$16 + 8 * S$} from the beginning of the section), and
-consists of an array of $M$ 32-bit slots,
+consists of an array of $S$ 4-byte slots,
 % (using the byte order of the application binary), 
 corresponding 1-1 with slots in the hash
 table. Each entry in the parallel table contains a row index into
@@ -463,31 +526,30 @@ Unused slots in the hash table have 0 in both the hash table
 entry and the parallel table entry. While 0 is a valid hash
 value, the row index in a used slot will always be non-zero.
 
-Given a 64-bit compilation unit signature or a type signature $X$,
+Given an 8-byte compilation unit ID or type signature $X$,
 an entry in the hash table is located as follows:
 \begin{enumerate}[1. ]
-\item Calculate a primary hash $H = X\ \&\ MASK(k)$, where $MASK(k)$ is a
-    mask with the low-order $k$ bits all set to 1.
-
-\item Calculate a secondary hash $H' = (((X>>32)\ \&\ MASK(k))\ |\ 1)$.
-
+\item Define $REP(X)$ to be the value of $X$ interpreted as an 
+      unsigned 64-bit integer in the target byte order.
+\item Calculate a primary hash $H = REP(X)\ \&\ MASK(k)$, where
+      $MASK(k)$ is a mask with the low-order $k$ bits all set to 1.
+\item Calculate a secondary hash $H' = (((REP(X)>>32)\ \&\ MASK(k))\ |\ 1)$.
 \item If the hash table entry at index $H$ matches the signature, use
-    that entry. If the hash table entry at index $H$ is unused (all
-    zeroes), terminate the search: the signature is not present
-    in the table.
-
-\item Let $H = (H + H')\ modulo\ M$. Repeat at Step 3.
+      that entry. If the hash table entry at index $H$ is unused (all
+      zeroes), terminate the search: the signature is not present
+      in the table.
+\item Let $H = (H + H')\ modulo\ S$. Repeat at Step 4.
 \end{enumerate}
 
-Because $M > U$, and $H'$ and $M$ are relatively prime, the search is
+Because $S > U$, and $H'$ and $S$ are relatively prime, the search is
 guaranteed to stop at an unused slot or find the match.
 
 \needlines{4}
 The table of offsets begins immediately following the parallel
 table (at offset \mbox{$16 + 12 * S$} from the beginning of the section).
-The table is a two-dimensional array of 32-bit words, 
-%(using the byte order of the application binary), 
-with $C$ columns and $U + 1$
+The table is a two-dimensional array of 4-byte words, 
+%(using the byte order of the application binary),
+with $N$ sections and $U + 1$
 rows, in row-major order. Each row in the array is indexed
 starting from 0. The first row provides a key to the columns:
 each column in this row provides a section identifier for a debug
@@ -495,6 +557,8 @@ section, and the offsets in the same column of subsequent rows
 refer to that section. The section identifiers are shown in
 Table \referfol{tab:dwarfpackagefilesectionidentifierencodings}.
 
+\textit{Not all sections listed in the table need be included.}
+
 \needlines{12}
 \begin{centering}
 \setlength{\extrarowheight}{0.1cm}
@@ -521,44 +585,53 @@ Table \referfol{tab:dwarfpackagefilesectionidentifierencodings}.
 \end{longtable}
 \end{centering}
 
-The offsets provided by the CU and TU index sections are the base
-offsets for the contributions made by each CU or TU to the
+The offsets provided by the CU and TU index sections are the 
+base offsets for the contributions made by each CU or TU to the
 corresponding section in the package file. Each CU and TU header
-contains an \texttt{abbrev\_offset} field, used to find the abbreviations
+contains a \HFNdebugabbrevoffset{} field, used to find the abbreviations
 table for that CU or TU within the contribution to the
-\dotdebugabbrevdwo{} section for that CU or TU, and should be
+\dotdebugabbrevdwo{} section for that CU or TU, and are
 interpreted as relative to the base offset given in the index
 section. Likewise, offsets into \dotdebuglinedwo{} from
-\DWATstmtlist{} attributes should be interpreted as relative to
+\DWATstmtlist{} attributes are interpreted as relative to
 the base offset for \dotdebuglinedwo{}, and offsets into other debug
-sections obtained from DWARF attributes should also be
+sections obtained from DWARF attributes are also 
 interpreted as relative to the corresponding base offset.
 
 The table of sizes begins immediately following the table of
 offsets, and provides the sizes of the contributions made by each
 CU or TU to the corresponding section in the package file. Like
-the table of offsets, it is a two-dimensional array of 32-bit
-words, with $C$ columns and $U$ rows, in row-major order. Each row in
+the table of offsets, it is a two-dimensional array of 4-byte
+words, with $N$ 
+entries and $U$ rows, in row-major order. Each row in
 the array is indexed starting from 1 (row 0 of the table of
 offsets also serves as the key for the table of sizes).
 
+For an example, see Figure \refersec{fig:examplecuindexsection}.
+
 \subsection{DWARF Supplementary Object Files}
-\label{data:dwarfsupplemetaryobjectfiles}
-In order to minimize the size of debugging information, it is possible
-to move duplicate debug information entries, strings and macro entries from
-several executables or shared objects into a separate 
-\addtoindexi{\textit{supplementary object file}}{supplementary object file} by some
-post-linking utility; the moved entries and strings can be then referenced
-from the debugging information of each of those executables or shared objects.
+\label{datarep:dwarfsupplemetaryobjectfiles}
+In order to minimize the size of debugging information, 
+it is possible to move duplicate debug information entries, 
+strings and macro entries from several executables or shared 
+object files into a separate 
+\addtoindexi{\textit{supplementary object file}}{supplementary object file} 
+by some post-linking utility; the moved entries and strings can 
+then be referenced
+from the debugging information of each of those executable or 
+shared object files.
+
+This facilitates distribution of separate consolidated debug files in
+a simple manner.
 
 \needlines{4}
 A DWARF \addtoindex{supplementary object file} is itself an object file, 
 using the same object
-file format, byte order, and size as the corresponding application executables
+file format, \byteorder{}, and size as the corresponding application executables
 or shared libraries. It consists only of a file header, section table, and
 a number of DWARF debug information sections.  Both the 
 \addtoindex{supplementary object file}
-and all the executables or shared objects that reference entries or strings in that
+and all the executable or shared object files that reference entries or strings in that
 file must contain a \dotdebugsup{} section that establishes the relationship.
 
 The \dotdebugsup{} section contains:
@@ -566,14 +639,15 @@ The \dotdebugsup{} section contains:
 \item \texttt{version} (\HFTuhalf) \\
 \addttindexx{version}
 A 2-byte unsigned integer representing the version of the DWARF
-information for the compilation unit (see Appendix G). The
-value in this field is \versiondotdebugsup.
+information for the compilation unit. 
+
+The value in this field is \versiondotdebugsup.
 
 \item \texttt{is\_supplementary} (\HFTubyte) \\
 \addttindexx{is\_supplementary}
 A 1-byte unsigned integer, which contains the value 1 if it is
-in the \addtoindex{supplementary object file} that other executables or 
-shared objects refer to, or 0 if it is an executable or shared object 
+in the \addtoindex{supplementary object file} that other executable or 
+shared object files refer to, or 0 if it is an executable or shared object 
 referring to a \addtoindex{supplementary object file}.
 
 \needlines{4}
@@ -589,44 +663,41 @@ is not needed and must be an empty string (a single null byte).
 \item \texttt{sup\_checksum\_len} (unsigned LEB128) \\
 \addttindexx{sup\_checksum\_len}
 Length of the following \addttindex{sup\_checksum} field; 
-his value can be 0 if no checksum is provided.
-
+this value can be 0 if no checksum is provided.
 
 \item \texttt{sup\_checksum} (array of \HFTubyte) \\
 \addttindexx{sup\_checksum}
-Some checksum or cryptographic hash function of the \dotdebuginfo{}, 
-\dotdebugstr{} and \dotdebugmacro{} sections of the 
-\addtoindex{supplementary object file}, or some unique identifier
-which the implementation can choose to verify that the supplementary 
-section object file matches what the debug information in the executables 
-or shared objects expects.
+An implementation-defined integer constant value that
+provides unique identification of the supplementary file.
+
 \end{enumerate}
 
 Debug information entries that refer to an executable's or shared
-object's addresses must \emph{not} be moved to supplementary files (the
-addesses will likely not be the same). Similarly,
-entries referenced from within location expressions or using loclistptr
+object's addresses must \emph{not} be moved to supplementary files 
+(the addesses will likely not be the same). Similarly,
+entries referenced from within location descriptions or using loclistptr
 form attributes must not be moved to a \addtoindex{supplementary object file}.
 
-Executable or shared object compilation units can use
+Executable or shared object file compilation units can use
 \DWTAGimportedunit{} with \DWFORMrefsup{} form \DWATimport{} attribute
 to import entries from the \addtoindex{supplementary object file}, other \DWFORMrefsup{}
 attributes to refer to them and \DWFORMstrpsup{} form attributes to
 refer to strings that are used by debug information of multiple
-executables or shared objects.  Within the \addtoindex{supplementary object file}'s
-debugging sections, form \DWFORMrefsup{} or \DWFORMstrpsup{} should
-not be used, and all reference forms referring to some other sections
+executables or shared object files.  Within the \addtoindex{supplementary object file}'s
+debugging sections, form \DWFORMrefsup{} or \DWFORMstrpsup{} are
+not used, and all reference forms referring to some other sections
 refer to the local sections in the \addtoindex{supplementary object file}.
 
-In macro information, \DWMACROdefineindirectsup{} or
-\DWMACROundefindirectsup{} opcodes can refer to strings in the 
+In macro information, \DWMACROdefinesup{} or
+\DWMACROundefsup{} opcodes can refer to strings in the 
 \dotdebugstr{} section of the \addtoindex{supplementary object file}, 
-or \DWMACROtransparentincludesup{} 
+or \DWMACROimportsup{} 
 can refer to \dotdebugmacro{} section entries.  Within the 
 \dotdebugmacro{} section of a \addtoindex{supplementary object file}, 
-\DWMACROdefineindirect{} and \DWMACROundefindirect{}
-opcodes refer to the local \dotdebugstr{} section, not the one in
-the executable or shared object."
+\DWMACROdefinestrp{} and \DWMACROundefstrp{}
+opcodes refer to the local \dotdebugstr{} section in that
+supplementary file, not the one in
+the executable or shared object file.
 
 
 \needlines{6}
@@ -635,17 +706,23 @@ the executable or shared object."
 \hypertarget{datarep:xxbitdwffmt}{}
 \addtoindexx{32-bit DWARF format}
 \addtoindexx{64-bit DWARF format}
-There are two closely related file formats. In the 32-bit DWARF
+There are two closely-related DWARF
+formats. In the 32-bit DWARF
 format, all values that represent lengths of DWARF sections
 and offsets relative to the beginning of DWARF sections are
-represented using 32-bits. In the 64-bit DWARF format, all
+represented using four bytes. In the 64-bit DWARF format, all
 values that represent lengths of DWARF sections and offsets
 relative to the beginning of DWARF sections are represented
-using 64-bits. A special convention applies to the initial
+using eight bytes. A special convention applies to the initial
 length field of certain DWARF sections, as well as the CIE and
 FDE structures, so that the 32-bit and 64-bit DWARF formats
 can coexist and be distinguished within a single linked object.
 
+Except where noted otherwise, all references in this document
+to a debugging information section (for example, \dotdebuginfo),
+apply also to the corresponding split DWARF section (for example,
+\dotdebuginfodwo).
+
 The differences between the 32- and 64-bit DWARF formats are
 detailed in the following:
 \begin{enumerate}[1. ]
@@ -654,15 +731,15 @@ detailed in the following:
 \addtoindex{initial length} field (see 
 \addtoindexx{initial length!encoding}
 Section \ref{datarep:initiallengthvalues} on page \pageref{datarep:initiallengthvalues})
-is an unsigned 32-bit integer (which
+is an unsigned 4-byte integer (which
 must be less than \xfffffffzero); in the 64-bit DWARF format,
-an \addtoindex{initial length} field is 96 bits in size,
+an \addtoindex{initial length} field is 12 bytes in size,
 and has two parts:
 \begin{itemize}
-\item The first 32-bits have the value \xffffffff.
+\item The first four bytes have the value \xffffffff.
 
-\item  The following 64-bits contain the actual length
-represented as an unsigned 64-bit integer.
+\item  The following eight bytes contain the actual length
+represented as an unsigned 8-byte integer.
 \end{itemize}
 
 \textit{This representation allows a DWARF consumer to dynamically
@@ -670,16 +747,16 @@ detect that a DWARF section contribution is using the 64-bit
 format and to adapt its processing accordingly.}
 
 \needlines{4}
-\item Section offset and section length
-\hypertarget{datarep:sectionoffsetlength}{} 
+\item \hypertarget{datarep:sectionoffsetlength}{}
+Section offset and section length
 \addtoindexx{section length!use in headers}
 fields that occur
 \addtoindexx{section offset!use in headers}
 in the headers of DWARF sections (other than initial length
 \addtoindexx{initial length}
 fields) are listed following. In the 32-bit DWARF format these
-are 32-bit unsigned integer values; in the 64-bit DWARF format,
-they are 64-bit unsigned integer values.
+are 4-byte unsigned integer values; in the 64-bit DWARF format,
+they are 8-byte unsigned integer values.
 
 \begin{center}
 \begin{tabular}{lll}
@@ -704,8 +781,8 @@ each other (both offset and size).
 \item Within the body of the \dotdebuginfo{}
 section, certain forms of attribute value depend on the choice
 of DWARF format as follows. For the 32-bit DWARF format,
-the value is a 32-bit unsigned integer; for the 64-bit DWARF
-format, the value is a 64-bit unsigned integer.
+the value is a 4-byte unsigned integer; for the 64-bit DWARF
+format, the value is an 8-byte unsigned integer.
 \begin{center}
 \begin{tabular}{lp{6cm}}
 Form             & Role  \\ \hline
@@ -724,8 +801,8 @@ Form             & Role  \\ \hline
 \needlines{5}
 \item Within the body of the \dotdebugline{} section, certain forms of content
 description depend on the choice of DWARF format as follows: for the
-32-bit DWARF format, the value is a 32-bit unsigned integer; for the
-64-bit DWARF format, the value is a 64-bit unsigned integer.
+32-bit DWARF format, the value is a 4-byte unsigned integer; for the
+64-bit DWARF format, the value is a 8-byte unsigned integer.
 \begin{center}
 \begin{tabular}{lp{6cm}}
 Form             & Role  \\ \hline
@@ -739,15 +816,15 @@ compilation units (CUs) and the array of local type units
 (TUs), which represents an offset in the 
 \dotdebuginfo{}
 section, depends on the DWARF format as follows: in the
-32-bit DWARF format, each entry is a 32-bit unsigned integer;
-in the 64-bit DWARF format, it is a 64-bit unsigned integer.
+32-bit DWARF format, each entry is a 4-byte unsigned integer;
+in the 64-bit DWARF format, it is a 8-byte unsigned integer.
 
 \needlines{4}
-\item In the body of the \dotdebugstroffsets{} and \dotdebugstroffsetsdwo{}
+\item In the body of the \dotdebugstroffsets{} 
 sections, the size of entries in the body depend on the DWARF
-format as follows: in the 32-bit DWARF format, entries are 32-bit
+format as follows: in the 32-bit DWARF format, entries are 4-byte
 unsigned integer values; in the 64-bit DWARF format, they are
-64-bit unsigned integers.
+8-byte unsigned integers.
 
 \item In the body of the \dotdebugaddr{}, \dotdebugloc{} and \dotdebugranges{}
 sections, the contents of the address size fields depends on the
@@ -774,7 +851,7 @@ reporting of all such errors.)
 \textit{It is expected that DWARF producing compilers will \emph{not} use
 the 64-bit format \emph{by default}. In most cases, the division of
 even very large applications into a number of executable and
-shared objects will suffice to assure that the DWARF sections
+shared object files will suffice to assure that the DWARF sections
 within each individual linked object are less than 4 GBytes
 in size. However, for those cases where needed, the 64-bit
 format allows the unusual case to be handled as well. Even
@@ -784,7 +861,6 @@ separate 32-bit format versions of system supplied shared
 executable libraries can still be used.}
 
 
-
 \section{Format of Debugging Information}
 \label{datarep:formatofdebugginginformation}
 
@@ -804,7 +880,7 @@ contribution may also be made to the
 section of the object file. Each
 such contribution consists of a 
 \addtoindex{type unit} header 
-(see Section \refersec{datarep:typeunitheader}) 
+(see Section \refersec{datarep:typeunitheaders}) 
 followed by a \DWTAGtypeunit{} entry, together with
 its children.
 
@@ -847,12 +923,27 @@ enumeration are shown in Table \refersec{tab:unitheaderunitkindencodings}.
 \endlastfoot
 \DWUTcompileTARG~\ddag    &0x01 \\ 
 \DWUTtypeTARG~\ddag       &0x02 \\ 
-\DWUTpartialTARG~\ddag    &0x03 \\ \hline
+\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 Unit Header}
+\subsubsection{Compilation and Partial Unit Headers}
 \label{datarep:compilationunitheader}
 \begin{enumerate}[1. ]
 
@@ -872,25 +963,36 @@ integer that gives the actual length
 
 \item  \texttt{version} (\HFTuhalf) \\
 \addttindexx{version}
+\addtoindexx{version number!compilation unit}
 A 2-byte unsigned integer representing the version of the
-DWARF information for the compilation unit \addtoindexx{version number!compilation unit} 
-(see Appendix \refersec{app:dwarfsectionversionnumbersinformative}). 
+DWARF information for the compilation unit.
 The value in this field is \versiondotdebuginfo.
 
+\textit{See also Appendix \refersec{app:dwarfsectionversionnumbersinformative}
+for a summary of all version numbers that apply to DWARF sections.}
+
 \needlines{4}
 \item \texttt{unit\_type} (\HFTubyte) \\
 \addttindexx{unit\_type}
 A 1-byte unsigned integer identifying this unit as a compilation unit.
 The value of this field is 
-\DWUTcompile{} for a {normal compilation} unit or
-\DWUTpartial{} for a {partial compilation} unit
-(see Section \refersec{chap:normalandpartialcompilationunitentries}).
+\DWUTcompile{} for a full compilation unit or
+\DWUTpartial{} for a partial compilation unit
+(see Section \refersec{chap:fullandpartialcompilationunitentries}).
 
 \textit{This field is new in \DWARFVersionV.}
 
 \needlines{4}
-\item \addttindex{debug\_abbrev\_offset} (\livelink{datarep:sectionoffsetlength}{section offset}) \\
-\addttindexx{debug\_abbrev\_offset}
+\item \texttt{address\_size} (\HFTubyte) \\
+\addttindexx{address\_size}
+A 1-byte unsigned integer representing the size in bytes of
+an address on the target architecture. If the system uses
+\addtoindexx{address space!segmented}
+segmented addressing, this value represents the size of the
+offset portion of an address.
+
+\item \HFNdebugabbrevoffset{} (\livelink{datarep:sectionoffsetlength}{section offset}) \\
 A 
 \addtoindexx{section offset!in .debug\_info header}
 4-byte or 8-byte unsigned offset into the 
@@ -901,6 +1003,61 @@ the \thirtytwobitdwarfformat, this is a 4-byte unsigned 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).
+
+\needlines{4}
+\item \HFNunitpaddingTWO{} (4 or 8 bytes) \\
+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. ]
+
+\item \texttt{unit\_length} (\livelink{datarep:initiallengthvalues}{initial length}) \\
+\addttindexx{unit\_length}
+A 4-byte or 12-byte 
+\addtoindexx{initial length}
+unsigned integer representing the length
+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
+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 
+(see Section \refersec{datarep:32bitand64bitdwarfformats}).
+
+\item  \texttt{version} (\HFTuhalf) \\
+\addttindexx{version}
+\addtoindexx{version number!compilation unit}
+A 2-byte unsigned integer representing the version of the
+DWARF information for the compilation unit.
+The value in this field is \versiondotdebuginfo.
+
+\textit{See also Appendix \refersec{app:dwarfsectionversionnumbersinformative}
+for a summary of all version numbers that apply to DWARF sections.}
+
+\needlines{4}
+\item \texttt{unit\_type} (\HFTubyte) \\
+\addttindexx{unit\_type}
+A 1-byte unsigned integer identifying this unit as a compilation unit.
+The value of this field is 
+\DWUTskeleton{} for a skeleton compilation unit or
+\DWUTsplitcompile{} for a split compilation unit
+(see Section \refersec{chap:skeletoncompilationunitentries}).
+
+\textit{This field is new in \DWARFVersionV.}
+
+\needlines{4}
 \item \texttt{address\_size} (\HFTubyte) \\
 \addttindexx{address\_size}
 A 1-byte unsigned integer representing the size in bytes of
@@ -909,18 +1066,43 @@ an address on the target architecture. If the system uses
 segmented addressing, this value represents the size of the
 offset portion of an address.
 
-\end{enumerate}
+\item \HFNdebugabbrevoffset{} (\livelink{datarep:sectionoffsetlength}{section offset}) \\
+A 
+\addtoindexx{section offset!in .debug\_info header}
+4-byte or 8-byte unsigned offset into the 
+\dotdebugabbrev{}
+section. This offset associates the compilation unit with a
+particular set of debugging information entry abbreviations. In
+the \thirtytwobitdwarfformat, this is a 4-byte unsigned length;
+in the \sixtyfourbitdwarfformat, this is an 8-byte unsigned length
+(see Section \refersec{datarep:32bitand64bitdwarfformats}).
 
-\subsubsection{Type Unit Header}
-\label{datarep:typeunitheader}
+\needlines{6}
+\item \HFNdwoid{} (unit ID) \\
+An 8-byte implementation-defined integer constant value, 
+known as the compilation unit ID, that provides 
+unique identification of a skeleton compilation 
+unit and its associated split compilation unit in 
+the object file named in the \DWATdwoname{} attribute
+of the skeleton compilation.
+
+\needlines{4}
+\item \HFNunitpaddingTWO{} (4 or 8 bytes) \\
+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}
+\subsubsection{Type Unit Headers}
+\label{datarep:typeunitheaders}
 The header for the series of debugging information entries
 contributing to the description of a type that has been
 placed in its own \addtoindex{type unit}, within the 
 \dotdebuginfo{} section,
 consists of the following information:
 \begin{enumerate}[1. ]
-
 \item \texttt{unit\_length} (\livelink{datarep:initiallengthvalues}{initial length}) \\
 \addttindexx{unit\_length}
 A 4-byte or 12-byte unsigned integer 
@@ -937,33 +1119,27 @@ consists of the 4-byte value \wffffffff followed by an
 \needlines{4}
 \item  \texttt{version} (\HFTuhalf) \\
 \addttindexx{version}
+\addtoindexx{version number!type unit}
 A 2-byte unsigned integer representing the version of the
-DWARF information for the 
-type unit\addtoindexx{version number!type unit} 
-(see Appendix \refersec{app:dwarfsectionversionnumbersinformative}). 
+DWARF information for the type unit.
 The value in this field is \versiondotdebuginfo.
 
 \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 type unit
-(see Section \refersec{chap:typeunitentries}).
+The value of this field is \DWUTtype{} for a 
+\bb
+non-split
+\eb
+type unit
+(see Section \refersec{chap:typeunitentries})
+\bb
+or \DWUTsplittype{} for a split type unit.
+\eb
 
 \textit{This field is new in \DWARFVersionV.}
 
-\needlines{4}
-\item \addttindex{debug\_abbrev\_offset} (\livelink{datarep:sectionoffsetlength}{section offset}) \\
-\addttindexx{debug\_abbrev\_offset}
-A 
-\addtoindexx{section offset!in .debug\_info header}
-4-byte or 8-byte unsigned offset into the 
-\dotdebugabbrev{}
-section. This offset associates the type unit with a
-particular set of debugging information entry abbreviations. In
-the \thirtytwobitdwarfformat, this is a 4-byte unsigned length;
-in the \sixtyfourbitdwarfformat, this is an 8-byte unsigned length
-(see Section \refersec{datarep:32bitand64bitdwarfformats}).
-
 \needlines{4}
 \item \texttt{address\_size} (\HFTubyte) \\
 \addttindexx{address\_size}
@@ -975,10 +1151,22 @@ an address on the target architecture. If the system uses
 segmented addressing, this value represents the size of the
 offset portion of an address.
 
+\needlines{6}
+\item \HFNdebugabbrevoffset{} (\livelink{datarep:sectionoffsetlength}{section offset}) \\
+A 
+\addtoindexx{section offset!in .debug\_info header}
+4-byte or 8-byte unsigned offset into the 
+\dotdebugabbrev{}
+section. This offset associates the type unit with a
+particular set of debugging information entry abbreviations. In
+the \thirtytwobitdwarfformat, this is a 4-byte unsigned length;
+in the \sixtyfourbitdwarfformat, this is an 8-byte unsigned length
+(see Section \refersec{datarep:32bitand64bitdwarfformats}).
+
 \item \texttt{type\_signature} (8-byte unsigned integer) \\
 \addttindexx{type\_signature}
 \addtoindexx{type signature}
-A 64-bit unique signature (see Section 
+A unique 8-byte signature (see Section 
 \refersec{datarep:typesignaturecomputation})
 of the type described in this type
 unit.  
@@ -988,6 +1176,7 @@ unit.
 the primary type contained in this 
 \addtoindex{type unit} uses this value.}
 
+\needlines{8}
 \item \texttt{type\_offset} (\livelink{datarep:sectionoffsetlength}{section offset}) \\
 \addttindexx{type\_offset}
 A 4-byte or 8-byte unsigned offset 
@@ -1048,10 +1237,10 @@ number that encodes the entry\textquoteright s tag. The encodings for the
 tag names are given in 
 Table \refersec{tab:tagencodings}.
 
+\needlines{6}
 \begin{centering}
 \setlength{\extrarowheight}{0.1cm}
 \begin{longtable}{l|c}
-  \hline
   \caption{Tag encodings} \label{tab:tagencodings} \\
   \hline \bfseries Tag name&\bfseries Value\\ \hline
 \endfirsthead
@@ -1116,6 +1305,11 @@ Table \refersec{tab:tagencodings}.
 \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      \\
 \DWTAGtypeunit & 0x41      \\
@@ -1127,11 +1321,16 @@ Table \refersec{tab:tagencodings}.
 \DWTAGatomictype~\ddag & 0x47 \\
 \DWTAGcallsite~\ddag & 0x48 \\
 \DWTAGcallsiteparameter~\ddag & 0x49 \\
+\bb
+\DWTAGskeletonunit~\ddag & 0x4a
+\eb
+\\
 \DWTAGlouser&0x4080      \\
 \DWTAGhiuser&\xffff      \\
 \end{longtable}
 \end{centering}
 
+\needlines{8}
 Following the tag encoding is a 1-byte value that determines
 whether a debugging information entry using this abbreviation
 has child entries or not. If the value is 
@@ -1182,6 +1381,7 @@ number representing the attribute\textquoteright s form.
 The series of attribute specifications ends with an
 entry containing 0 for the name and 0 for the form.
 
+\needlines{4}
 The attribute form 
 \DWFORMindirectTARG{} is a special case. For
 attributes with this form, the attribute value itself in the
@@ -1242,8 +1442,8 @@ Table \referfol{tab:attributeencodings}.
         \livelink{chap:classreference}{reference}
             \addtoindexx{byte size attribute} \\
 \textit{Reserved}&0x0c\footnote{Code 0x0c is reserved to allow backward compatible support of the 
-                                       DW\_AT\_bit\_offset \mbox{attribute} which was 
-                                       defined in \DWARFVersionIII{} and earlier.}
+             DW\_AT\_bit\_offset \mbox{attribute} which was 
+             defined in \DWARFVersionIII{} and earlier.}
        &\livelink{chap:classconstant}{constant}, 
         \livelink{chap:classexprloc}{exprloc}, 
         \livelink{chap:classreference}{reference}
@@ -1354,10 +1554,10 @@ Table \referfol{tab:attributeencodings}.
             \addtoindexx{friend attribute}  \\
 \DWATidentifiercase&0x42&\livelink{chap:classconstant}{constant} 
             \addtoindexx{identifier case attribute}  \\
-\DWATmacroinfo\footnote{\raggedright Not used in \DWARFVersionV. 
-                        Reserved for compatibility and coexistence
-                        with prior DWARF versions.}
-            &0x43&\livelink{chap:classmacptr}{macptr} 
+\textit{Reserved}&0x43\footnote{Code 0x43 is reserved to allow backward compatible support of the 
+             DW\_AT\_macro\_info \mbox{attribute} which was 
+             defined in \DWARFVersionIV{} and earlier.}
+            &\livelink{chap:classmacptr}{macptr} 
             \addtoindexx{macro information attribute (legacy)!encoding}  \\
 \DWATnamelistitem&0x44&\livelink{chap:classreference}{reference} 
             \addtoindexx{name list item attribute}  \\
@@ -1470,7 +1670,7 @@ Table \referfol{tab:attributeencodings}.
         \livelink{chap:classexprloc}{exprloc}
             \addtoindexx{rank attribute}  \\
 \DWATstroffsetsbase~\ddag&0x72&
-               \livelinki{chap:classstring}{stroffsetsptr}{stroffsetsptr class}
+               \livelinki{chap:classstroffsetsptr}{stroffsetsptr}{stroffsetsptr class}
             \addtoindexx{string offsets base!encoding} \\
 \DWATaddrbase~\ddag &0x73&
                \livelinki{chap:classaddrptr}{addrptr}{addrptr class}
@@ -1478,9 +1678,10 @@ Table \referfol{tab:attributeencodings}.
 \DWATrangesbase~\ddag&0x74&
                \livelinki{chap:classrangelistptr}{rangelistptr}{rangelistptr class}
             \addtoindexx{ranges base!encoding} \\
-\DWATdwoid~\ddag &0x75&
-               \livelink{chap:classconstant}{constant}
-            \addtoindexx{split DWARF object id!encoding} \\
+\bb
+\textit{Reserved} &0x75& \textit{Unused}
+\eb
+\\
 \DWATdwoname~\ddag &0x76&
                \livelink{chap:classstring}{string}
             \addtoindexx{split DWARF object file name!encoding} \\
@@ -1488,7 +1689,7 @@ Table \referfol{tab:attributeencodings}.
         \livelink{chap:classflag}{flag} \\
 \DWATrvaluereference~\ddag &0x78&
         \livelink{chap:classflag}{flag} \\
-\DWATmacros~\ddag &0x79&\livelink{chap:classmacptr}{macptr} 
+\DWATmacros~\ddag &0x79&\livelink{chap:classmacptr}{macptr}
         \addtoindexx{macro information attribute}  \\
 \DWATcallallcalls~\ddag &0x7a&\CLASSflag
         \addtoindexx{all calls summary attribute} \\
@@ -1556,9 +1757,23 @@ the list of classes allowed by the applicable attribute in
 Table \refersec{tab:attributeencodings}
 determines the class of the form.
 
+\needlines{4}
+In the form descriptions that follow, some forms are said
+to depend in part on the value of an attribute of the
+\definition{\associatedcompilationunit}:
+\begin{itemize}
+\item
+In the case of a \splitDWARFobjectfile{}, the associated
+compilation unit is the skeleton compilation unit corresponding 
+to the containing unit.
+\item Otherwise, the associated compilation unit 
+is the containing unit.
+\end{itemize}
 
 \needlines{4}
-Each possible form belongs to one or more of the following classes:
+Each possible form belongs to one or more of the following classes
+(see Table \refersec{tab:classesofattributevalue} for a summary of
+the purpose and general usage of each class):
 
 \begin{itemize}
 \item \livelinki{chap:classaddress}{address}{address class} \\
@@ -1571,7 +1786,7 @@ address on the target machine
 The size is encoded in the compilation unit header 
 (see Section \refersec{datarep:compilationunitheader}).
 This address is relocatable in a relocatable object file and
-is relocated in an executable file or shared object.
+is relocated in an executable file or shared object file.
 
 \item An indirect index into a table of addresses (as 
 described in the previous bullet) in the
@@ -1581,6 +1796,7 @@ The representation of a \DWFORMaddrxNAME{} value is an unsigned
 index into an array of addresses in the \dotdebugaddr{} section.
 The index is relative to the value of the \DWATaddrbase{} attribute 
 of the associated compilation unit.
+
 \end{itemize}
 
 \needlines{5}
@@ -1591,7 +1807,7 @@ consists of an offset from the beginning of the \dotdebugaddr{} section to the
 beginning of the list of machine addresses information for the
 referencing entity. It is relocatable in
 a relocatable object file, and relocated in an executable or
-shared object. In the \thirtytwobitdwarfformat, this offset
+shared object file. In the \thirtytwobitdwarfformat, this offset
 is a 4-byte unsigned value; in the 64-bit DWARF
 format, it is an 8-byte unsigned value (see Section
 \refersec{datarep:32bitand64bitdwarfformats}).
@@ -1602,27 +1818,24 @@ format, it is an 8-byte unsigned value (see Section
 \item \livelink{chap:classblock}{block} \\
 \livetarg{datarep:classblock}{}
 Blocks come in four forms:
-
-\begin{myindentpara}{1cm}
+\begin{itemize}
+\item
 A 1-byte length followed by 0 to 255 contiguous information
 bytes (\DWFORMblockoneTARG).
-\end{myindentpara}
 
-\begin{myindentpara}{1cm}
+\item
 A 2-byte length followed by 0 to 65,535 contiguous information
 bytes (\DWFORMblocktwoTARG).
-\end{myindentpara}
 
-\begin{myindentpara}{1cm}
+\item
 A 4-byte length followed by 0 to 4,294,967,295 contiguous
 information bytes (\DWFORMblockfourTARG).
-\end{myindentpara}
 
-\begin{myindentpara}{1cm}
+\item
 An unsigned LEB128\addtoindexx{LEB128!unsigned}
 length followed by the number of bytes
 specified by the length (\DWFORMblockTARG).
-\end{myindentpara}
+\end{itemize}
 
 In all forms, the length is the number of information bytes
 that follow. The information bytes may contain any mixture
@@ -1639,10 +1852,10 @@ constant data forms for one-, two-, four-, eight- and sixteen-byte values
 \DWFORMdatafourTARG,
 \DWFORMdataeightTARG{} and
 \DWFORMdatasixteenTARG). 
-There are also variable length constant
-data forms encoded using LEB128 numbers (see below). 
-Both signed (\DWFORMsdataTARG) and unsigned 
-(\DWFORMudataTARG) variable length constants are available.
+There are variable length constant
+data forms encoded using 
+signed LEB128 numbers (\DWFORMsdataTARG) and unsigned 
+LEB128 numbers (\DWFORMudataTARG).
 There is also an implicit constant (\DWFORMimplicitconst),
 whose value is provided as part of the abbreviation
 declaration.
@@ -1658,7 +1871,7 @@ be a signed integer, an unsigned integer, a floating\dash point
 constant, or anything else. A consumer must use context to
 know how to interpret the bits, which if they are target
 machine data (such as an integer or floating-point constant)
-will be in target machine byte\dash order.
+will be in target machine \byteorder.
 
 \textit{If one of the \DWFORMdataTARG\textless n\textgreater 
 forms is used to represent a
@@ -1681,6 +1894,7 @@ The information bytes contain a DWARF expression
 or location description 
 (see Section \refersec{chap:locationdescriptions}).
 
+\needlines{4}
 \item \livelinki{chap:classflag}{flag}{flag class} \\
 \livetarg{datarep:classflag}{}
 A flag \addtoindexx{flag class}
@@ -1689,11 +1903,12 @@ is represented explicitly as a single byte of data
 implicitly (\DWFORMflagpresentTARG). 
 In the
 first case, if the \nolink{flag} has value zero, it indicates the
-absence of the attribute; if the \nolink{flag} has a non\dash zero value,
+absence of the attribute; if the \nolink{flag} has a non-zero value,
 it indicates the presence of the attribute. In the second
 case, the attribute is implicitly indicated as present, and
 no value is encoded in the debugging information entry itself.
 
+\needlines{4}
 \item \livelinki{chap:classlineptr}{lineptr}{lineptr class} \\
 \livetarg{datarep:classlineptr}{}
 This is an offset into 
@@ -1707,7 +1922,7 @@ section to the first byte of
 the data making up the line number list for the compilation
 unit. 
 It is relocatable in a relocatable object file, and
-relocated in an executable or shared object. In the 
+relocated in an executable or shared object file. In the 
 \thirtytwobitdwarfformat, this offset is a 4-byte unsigned value;
 in the \sixtyfourbitdwarfformat, it is an 8-byte unsigned value
 (see Section \refersec{datarep:32bitand64bitdwarfformats}).
@@ -1727,7 +1942,7 @@ section to the first byte of
 the data making up the 
 \addtoindex{location list} for the compilation unit. 
 It is relocatable in a relocatable object file, and
-relocated in an executable or shared object. In the 
+relocated in an executable or shared object file. In the 
 \thirtytwobitdwarfformat, this offset is a 4-byte unsigned value;
 in the \sixtyfourbitdwarfformat, it is an 8-byte unsigned value
 (see Section \refersec{datarep:32bitand64bitdwarfformats}).
@@ -1745,7 +1960,7 @@ It consists of an offset from the beginning of the
 section to the the header making up the 
 macro information list for the compilation unit. 
 It is relocatable in a relocatable object file, and
-relocated in an executable or shared object. In the 
+relocated in an executable or shared object file. In the 
 \thirtytwobitdwarfformat, this offset is a 4-byte unsigned value;
 in the \sixtyfourbitdwarfformat, it is an 8-byte unsigned value
 (see Section \refersec{datarep:32bitand64bitdwarfformats}).
@@ -1760,11 +1975,14 @@ offset into the \dotdebugranges{} section
 It consists of an
 offset from the beginning of the 
 \dotdebugranges{} section
-to the beginning of the non\dash contiguous address ranges
+to the beginning of the non-contiguous address ranges
 information for the referencing entity.  
 It is relocatable in
 a relocatable object file, and relocated in an executable or
-shared object. In the \thirtytwobitdwarfformat, this offset
+shared object file. 
+However, if a \DWATrangesbase{} attribute applies, the offset
+is relative to the base offset given by \DWATrangesbase.
+In the \thirtytwobitdwarfformat, this offset
 is a 4-byte unsigned value; in the 64-bit DWARF
 format, it is an 8-byte unsigned value (see Section
 \refersec{datarep:32bitand64bitdwarfformats}).
@@ -1780,7 +1998,7 @@ format, it is an 8-byte unsigned value (see Section
 share a common representation, it is not possible for an
 attribute to allow more than one of these classes}
 
-
+\needlines{4}
 \begin{itemize}
 \item \livelinki{chap:classreference}{reference}{reference class} \\
 \livetarg{datarep:classreference}{}
@@ -1816,15 +2034,15 @@ information entry within a
 \dotdebuginfo{} section; in particular,
 it may refer to an entry in a different compilation unit
 from the unit containing the reference, and may refer to an
-entry in a different shared object.  This type of reference
+entry in a different shared object file.  This type of reference
 (\DWFORMrefaddrTARG) 
 is an offset from the beginning of the
 \dotdebuginfo{} 
-section of the target executable or shared object, or, for
+section of the target executable or shared object file, or, for
 references within a \addtoindex{supplementary object file}, 
 an offset from the beginning of the local \dotdebuginfo{} section;
 it is relocatable in a relocatable object file and frequently
-relocated in an executable file or shared object. For
+relocated in an executable or shared object file. For
 references from one shared object or static executable file
 to another, the relocation and identification of the target
 object must be performed by the consumer. In the 
@@ -1837,10 +2055,10 @@ unsigned value
 another compilation unit using 
 \DWFORMrefaddr{} must have a global symbolic name.}
 
-\textit{For a reference from one executable or shared object to
+\textit{For a reference from one executable or shared object file to
 another, the reference is resolved by the debugger to identify
-the shared object or executable and the offset into that
-object\textquoteright s \dotdebuginfo{}
+the executable or shared object file and the offset into that
+file\textquoteright s \dotdebuginfo{}
 section in the same fashion as the run
 time loader, either when the debug information is first read,
 or when the reference is used.}
@@ -1850,12 +2068,12 @@ information type entry that has been placed in its own
 \addtoindex{type unit}. This type of 
 reference (\DWFORMrefsigeightTARG) is the
 \addtoindexx{type signature}
-64-bit type signature 
+8-byte type signature 
 (see Section \refersec{datarep:typesignaturecomputation}) 
 that was computed for the type. 
 
 The fourth type of reference is a reference from within the 
-\dotdebuginfo{} section of the executable or shared object to
+\dotdebuginfo{} section of the executable or shared object file to
 a debugging information entry in the \dotdebuginfo{} section of 
 a \addtoindex{supplementary object file}.
 This type of reference (\DWFORMrefsupTARG) is an offset from the 
@@ -1867,7 +2085,7 @@ number of link\dash time relocations and so speed up linking. The
 use of the second, third and fourth type of reference allows for the
 sharing of information, such as types, across compilation
 units, while the fourth type further allows for sharing of information 
-across compilation units from different executables or shared objects.}
+across compilation units from different executables or shared object files.}
 
 \textit{A reference to any kind of compilation unit identifies the
 debugging information entry for that unit, not the preceding
@@ -1901,7 +2119,7 @@ value is a 4-byte unsigned offset; in the \sixtyfourbitdwarfformat,
 it is an 8-byte unsigned offset 
 (see Section \refersec{datarep:32bitand64bitdwarfformats}).
 
-\needlines{4}
+\needlines{6}
 \item as an indirect offset into the string table using an 
 index into a table of offsets contained in the 
 \dotdebugstroffsets{} section of the object file (\DWFORMstrxTARG).
@@ -1941,9 +2159,9 @@ This is an offset into the \dotdebugstroffsets{} section
 beginning of the string offsets information for the
 referencing entity. It is relocatable in
 a relocatable object file, and relocated in an executable or
-shared object. In the \thirtytwobitdwarfformat, this offset
-is a 4-byte unsigned value; in the 64-bit DWARF
-format, it is an 8-byte unsigned value (see Section
+shared object file. In the \thirtytwobitdwarfformat, this offset
+is a 4-byte unsigned value; in the \sixtyfourbitdwarfformat,
+it is an 8-byte unsigned value (see Section
 \refersec{datarep:32bitand64bitdwarfformats}).
 
 \textit{This class is new in \DWARFVersionV.}
@@ -2020,8 +2238,8 @@ Table \referfol{tab:attributeformencodings}.
 \label{datarep:variablelengthdata}
 \addtoindexx{variable length data|see {LEB128}}
 Integers may be 
-\addtoindexx{Little Endian Base 128|see{LEB128}}
-encoded using \doublequote{Little Endian Base 128}
+\addtoindexx{Little-Endian Base 128|see{LEB128}}
+encoded using \doublequote{Little-Endian Base 128}
 \addtoindexx{little-endian encoding|see{endian attribute}}
 (LEB128) numbers. 
 \addtoindexx{LEB128}
@@ -2030,8 +2248,8 @@ densely that exploits the assumption that most integers are
 small in magnitude.
 
 \textit{This encoding is equally suitable whether the target machine
-architecture represents data in big\dash\ endian or little\dash endian
-order. It is \doublequote{little\dash endian} only in the sense that it
+architecture represents data in big-endian or little-endian
+\byteorder. It is \doublequote{little-endian} only in the sense that it
 avoids using space to represent the \doublequote{big} end of an
 unsigned integer, when the big end is all zeroes or sign
 extension bits.}
@@ -2058,12 +2276,12 @@ numbers. The
 that an additional byte follows.
 
 
-The encoding for signed, two\textquoteright s complement LEB128 
+The encoding for signed, two\textquoteright{s} complement LEB128 
 (\addtoindex{SLEB128}) \addtoindexx{LEB128!signed, encoding as}
 numbers is similar, except that the criterion for discarding
 high order bytes is not whether they are zero, but whether
 they consist entirely of sign extension bits. Consider the
-32-bit integer -2. The three high level bytes of the number
+4-byte integer -2. The three high level bytes of the number
 are sign extension, thus LEB128 would represent it as a single
 byte containing the low order 7 bits, with the high order
 bit cleared to indicate the end of the byte stream. Note
@@ -2301,7 +2519,7 @@ offsets are the same size as an address on the target machine.
 For a \addtoindex{location list} to be specified, the base address of
 \addtoindexx{base address selection entry!in location list}
 the corresponding compilation unit must be defined 
-(see Section \refersec{chap:normalandpartialcompilationunitentries}).
+(see Section \refersec{chap:fullandpartialcompilationunitentries}).
 
 \subsubsection{Location List Entries in Split Objects}
 \label{datarep:locationlistentriesinsplitobjects}
@@ -2334,13 +2552,10 @@ Table \refersec{tab:locationlistentryencodingvalues}.
 \section{Base Type Attribute Encodings}
 \label{datarep:basetypeattributeencodings}
 
-The encodings of the 
-\hypertarget{chap:DWATencodingencodingofbasetype}{}
-constants used in 
-\addtoindexx{encoding attribute}
-the 
-\DWATencoding{}
-attribute are given in 
+The\hypertarget{chap:DWATencodingencodingofbasetype}{}
+encodings of the constants used in the 
+\DWATencodingDEFN{} attribute\addtoindexx{encoding attribute} 
+are given in 
 Table \refersec{tab:basetypeencodingvalues}
 
 \begin{centering}
@@ -2379,7 +2594,7 @@ Table \refersec{tab:basetypeencodingvalues}
 \end{longtable}
 \end{centering}
 
-\needlines{4}
+\vspace*{1cm}
 The encodings of the constants used in the 
 \DWATdecimalsign{} attribute 
 are given in 
@@ -2393,17 +2608,15 @@ Table \refersec{tab:decimalsignencodings}.
 \endfirsthead
   \bfseries Decimal sign code name&\bfseries Value\\ \hline
 \endhead
-  \hline \emph{Continued on next page}
-\endfoot
+%  \hline \emph{Continued on next page}
+%\endfoot
   \hline
 \endlastfoot
-
-\DWDSunsigned{} & 0x01  \\
-\DWDSleadingoverpunch{} & 0x02  \\
+\DWDSunsigned{}          & 0x01  \\
+\DWDSleadingoverpunch{}  & 0x02  \\
 \DWDStrailingoverpunch{} & 0x03  \\
-\DWDSleadingseparate{} & 0x04  \\
-\DWDStrailingseparate{} & 0x05  \\
-
+\DWDSleadingseparate{}   & 0x04  \\
+\DWDStrailingseparate{}  & 0x05 \\ 
 \end{longtable}
 \end{centering}
 
@@ -2566,7 +2779,7 @@ defined language.
 \DWLANGCeightynine &0x0001 &0 \addtoindexx{C:1989 (ISO)}      \\
 \DWLANGC{} &0x0002 &0  \addtoindexx{C!non-standard} \\
 \DWLANGAdaeightythree{} \dag &0x0003 &1  \addtoindexx{Ada:1983 (ISO)}     \\
-\DWLANGCplusplus{} &0x0004 &0 \addtoindexx{C++:1998 (ISO)}      \\
+\DWLANGCplusplus{} &0x0004 &0 \addtoindexx{C++98 (ISO)} \\
 \DWLANGCobolseventyfour{} \dag &0x0005 &1 \addtoindexx{COBOL:1974 (ISO)}      \\
 \DWLANGCoboleightyfive{} \dag &0x0006 &1 \addtoindexx{COBOL:1985 (ISO)}      \\
 \DWLANGFortranseventyseven &0x0007 &1 \addtoindexx{FORTRAN:1977 (ISO)}      \\
@@ -2587,17 +2800,21 @@ defined language.
 \DWLANGGo{} \dag \ddag &0x0016 &0 \addtoindexx{Go}\\
 \DWLANGModulathree{} \dag \ddag &0x0017 &1 \addtoindexx{Modula-3}\\
 \DWLANGHaskell{} \dag \ddag &0x0018 &0 \addtoindexx{Haskell}\\
-\DWLANGCpluspluszerothree{} \ddag &0x0019 &0 \addtoindexx{C++:2003 (ISO)}\\
-\DWLANGCpluspluseleven{} \ddag &0x001a &0 \addtoindexx{C++:2011 (ISO)}\\
+\DWLANGCpluspluszerothree{} \ddag &0x0019 &0 \addtoindexx{C++03 (ISO)}\\
+\DWLANGCpluspluseleven{} \ddag &0x001a &0 \addtoindexx{C++11 (ISO)} \\
 \DWLANGOCaml{} \ddag &0x001b &0        \addtoindexx{OCaml}\\
 \DWLANGRust{} \ddag &0x001c &0 \addtoindexx{Rust}\\
 \DWLANGCeleven{} \ddag &0x001d &0 \addtoindexx{C:2011 (ISO)}\\
 \DWLANGSwift{} \ddag &0x001e &0 \addtoindexx{Swift} \\
 \DWLANGJulia{} \ddag &0x001f &1 \addtoindexx{Julia} \\
 \DWLANGDylan{} \ddag &0x0020 &0 \addtoindexx{Dylan} \\
-\DWLANGCplusplusfourteen{}~\ddag &0x0021 &0 \addtoindexx{C++:2014 (ISO)}     \\
+\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 & \\
 
@@ -2766,59 +2983,8 @@ Table \refersec{tab:discriminantdescriptorencodings}.
 \needlines{6}
 \section{Name Index Table}
 \label{datarep:nameindextable}
-Each name index table in the \dotdebugnames{} section 
-begins with a header consisting of:
-\begin{enumerate}[1. ]
-\item \texttt{unit\_length} (\livelink{datarep:initiallengthvalues}{initial length}) \\
-\addttindexx{unit\_length}
-A 4-byte or 12-byte initial length field that 
-contains the size in bytes of this contribution to the \dotdebugnames{} 
-section, not including the length field itself
-(see Section \refersec{datarep:initiallengthvalues}).
-
-\item \texttt{version} (\HFTuhalf) \\
-A 2-byte version number\addtoindexx{version number!name index table} 
-(see Appendix \refersec{app:dwarfsectionversionnumbersinformative}). 
-This number is specific to the name index table and is
-independent of the DWARF version number.
-
-The value in this field is \versiondotdebugnames.
-
-\item padding (\HFTuhalf) \\
-
-\item \texttt{comp\_unit\_count} (\HFTuword) \\
-The number of CUs in the CU list.
-
-\item \texttt{local\_type\_unit\_count} (\HFTuword) \\
-The number of TUs in the first TU list.
-
-\item \texttt{foreign\_type\_unit\_count} (\HFTuword) \\
-The number of TUs in the second TU list.
-
-\item \texttt{bucket\_count} (\HFTuword) \\
-The number of hash buckets in the hash lookup table. 
-If there is no hash lookup table, this field contains 0.
-
-\item \texttt{name\_count} (\HFTuword) \\
-The number of unique names in the index.
-
-\item \texttt{abbrev\_table\_size} (\HFTuword) \\
-The size in bytes of the abbreviations table.
-
-\item \texttt{augmentation\_string\_size} (\HFTuword) \\
-The size in bytes of the augmentation string. This value should be
-rounded up to a multiple of 4.
-
-\item \texttt{augmentation\_string} (\HFTaugstring) \\
-A vendor-specific augmentation string, which provides additional 
-information about the contents of this index. If provided, the string
-should begin with a 4-character vendor ID. The remainder of the
-string is meant to be read by a cooperating consumer, and its
-contents and interpretation are not specified here. The
-string should be padded with null characters to a multiple of
-four bytes in length.
-
-\end{enumerate}
+The \addtoindexi{version number}{version number!name index table}
+in the name index table header is \versiondotdebugnames{}.
 
 The name index attributes and their encodings are listed in Table \referfol{datarep:indexattributeencodings}.
 
@@ -2826,14 +2992,14 @@ The name index attributes and their encodings are listed in Table \referfol{data
 \setlength{\extrarowheight}{0.1cm}
 \begin{longtable}{l|c|l}
   \caption{Name index attribute encodings} \label{datarep:indexattributeencodings}\\
-  \hline \bfseries Attribute name&\bfseries Value &\bfseries Form/Class \\ \hline
+  \hline \bfseries Attribute name &\bfseries Value &\bfseries Form/Class \\ \hline
 \endfirsthead
-  \bfseries Attribute name&\bfseries Value &\bfseries Form/Class \\ \hline
+  \bfseries Attribute name &\bfseries Value &\bfseries Form/Class \\ \hline
 \endhead
   \hline \emph{Continued on next page}
 \endfoot
   \hline
-  \ddag \ \textit{New in \DWARFVersionV}
+  \ddag~\textit{New in \DWARFVersionV}
 \endlastfoot
 \DWIDXcompileunit~\ddag & 1        & \CLASSconstant \\
 \DWIDXtypeunit~\ddag    & 2        & \CLASSconstant \\
@@ -2900,8 +3066,7 @@ the actual length
 
 \item version (\HFTuhalf) \\
 A 2-byte version identifier representing the version of the
-DWARF information for the address range table
-(see Appendix \refersec{app:dwarfsectionversionnumbersinformative}).
+DWARF information for the address range table.
 
 This value in this field \addtoindexx{version number!address range table} is 2. 
  
@@ -2924,18 +3089,16 @@ address
 \addtoindexx{address space!segmented}
 addressing) on the target system.
 
-\item \texttt{segment\_size} (\HFTubyte) \\
-A 
-\addttindexx{segment\_size}
-1-byte unsigned integer containing the size in bytes of a
+\item \HFNsegmentselectorsize{} (\HFTubyte) \\
+A 1-byte unsigned integer containing the size in bytes of a
 segment selector on the target system.
 
 \end{enumerate}
 
 This header is followed by a series of tuples. Each tuple
 consists of a segment, an address and a length. 
-The segment
-size is given by the \addttindex{segment\_size} field of the header; the
+The segment selector
+size is given by the \HFNsegmentselectorsize{} field of the header; the
 address and length size are each given by the \addttindex{address\_size}
 field of the header. 
 The first tuple following the header in
@@ -2945,7 +3108,7 @@ plus twice the \addtoindex{size of an address}).
 The header is padded, if
 necessary, to that boundary. Each set of tuples is terminated
 by a 0 for the segment, a 0 for the address and 0 for the
-length. If the \addttindex{segment\_size} field in the header is zero,
+length. If the \HFNsegmentselectorsize{} field in the header is zero,
 the segment selectors are omitted from all tuples, including
 the terminating tuple.
 
@@ -2954,8 +3117,7 @@ the terminating tuple.
 \label{datarep:linenumberinformation}
 
 The \addtoindexi{version number}{version number!line number information}
-in the line number program header is \versiondotdebugline{}
-(see Appendix \refersec{app:dwarfsectionversionnumbersinformative}). 
+in the line number program header is \versiondotdebugline{}.
 
 The boolean values \doublequote{true} and \doublequote{false} 
 used by the line number information program are encoded
@@ -3057,8 +3219,7 @@ Table \refersec{tab:linenumberheaderentryformatencodings}.
 \section{Macro Information}
 \label{datarep:macroinformation}
 The \addtoindexi{version number}{version number!macro information}
-in the macro information header is \versiondotdebugmacro{}
-(see Appendix \refersec{app:dwarfsectionversionnumbersinformative}). 
+in the macro information header is \versiondotdebugmacro{}.
 
 The source line numbers and source file indices encoded in the
 macro information section are represented as 
@@ -3085,20 +3246,20 @@ Table \refersec{tab:macroinfoentrytypeencodings}.
   \hline \ddag~\textit{New in DWARF Version 5}
 \endlastfoot
 
-\DWMACROdefine~\ddag              &0x01 \\
-\DWMACROundef~\ddag               &0x02 \\
-\DWMACROstartfile~\ddag           &0x03 \\
-\DWMACROendfile~\ddag             &0x04 \\
-\DWMACROdefineindirect~\ddag      &0x05 \\
-\DWMACROundefindirect~\ddag       &0x06 \\
-\DWMACROtransparentinclude~\ddag  &0x07 \\
-\DWMACROdefineindirectsup~\ddag   &0x08 \\
-\DWMACROundefindirectsup~\ddag    &0x09 \\
-\DWMACROtransparentincludesup~\ddag&0x0a \\
-\DWMACROdefineindirectx~\ddag     &0x0b \\
-\DWMACROundefindirectx~\ddag      &0x0c \\
-\DWMACROlouser~\ddag              &0xe0 \\
-\DWMACROhiuser~\ddag              &\xff \\
+\DWMACROdefine~\ddag          &0x01 \\
+\DWMACROundef~\ddag           &0x02 \\
+\DWMACROstartfile~\ddag       &0x03 \\
+\DWMACROendfile~\ddag         &0x04 \\
+\DWMACROdefinestrp~\ddag      &0x05 \\
+\DWMACROundefstrp~\ddag       &0x06 \\
+\DWMACROimport~\ddag          &0x07 \\
+\DWMACROdefinesup~\ddag       &0x08 \\
+\DWMACROundefsup~\ddag        &0x09 \\
+\DWMACROimportsup~\ddag       &0x0a \\
+\DWMACROdefinestrx~\ddag      &0x0b \\
+\DWMACROundefstrx~\ddag       &0x0c \\
+\DWMACROlouser~\ddag          &0xe0 \\
+\DWMACROhiuser~\ddag          &\xff \\
 
 \end{longtable}
 \end{centering}
@@ -3112,7 +3273,7 @@ CIE header is \xffffffff; in the \sixtyfourbitdwarfformat, the
 value is \xffffffffffffffff.
 
 The value of the CIE \addtoindexi{version number}{version number!call frame information}
-is 4 (see Appendix \refersec{app:dwarfsectionversionnumbersinformative}). 
+is \versiondotdebugframe.
 
 Call frame instructions are encoded in one or more bytes. The
 primary opcode is encoded in the high order two bits of
@@ -3194,7 +3355,7 @@ addresses are the same size as addresses on the target machine.
 For a \addtoindex{range list} to be specified, the base address of the
 \addtoindexx{base address selection entry!in range list}
 corresponding compilation unit must be defined 
-(see Section \refersec{chap:normalandpartialcompilationunitentries}).
+(see Section \refersec{chap:fullandpartialcompilationunitentries}).
 
 \needlines{6}
 \section{String Offsets Table}
@@ -3217,11 +3378,12 @@ Section \refersec{datarep:32bitand64bitdwarfformats}).
 
 %\needlines{4}
 \item  \texttt{version} (\HFTuhalf) \\
+\addtoindexx{version number!string offsets table}
 A 2-byte version identifier containing the value
-\versiondotdebugstroffsets{} 
-(see Appendix \refersec{app:dwarfsectionversionnumbersinformative}).
+\versiondotdebugstroffsets{}.
 
-\item \texttt{padding} (\HFTuhalf) \\
+\item \textit{padding} (\HFTuhalf) \\
+Reserved to DWARF (must be zero).
 \end{enumerate}
 
 This header is followed by a series of string table offsets
@@ -3252,9 +3414,9 @@ Section \refersec{datarep:32bitand64bitdwarfformats}).
 
 \needlines{4}
 \item  \texttt{version} (\HFTuhalf) \\
+\addtoindexx{version number!address table}
 A 2-byte version identifier containing the value
-\versiondotdebugaddr{} 
-(see Appendix \refersec{app:dwarfsectionversionnumbersinformative}).
+\versiondotdebugaddr{}.
 
 \needlines{4}
 \item  \texttt{address\_size} (\HFTubyte) \\
@@ -3264,15 +3426,15 @@ address for segmented addressing) on the target
 system.
 
 \needlines{4}
-\item  \texttt{segment\_size} (\HFTubyte) \\
+\item  \HFNsegmentselectorsize{} (\HFTubyte) \\
 A 1-byte unsigned integer containing the size in
 bytes of a segment selector on the target system.
 \end{enumerate}
 
 This header is followed by a series of segment/address pairs.
-The segment size is given by the \addttindex{segment\_size} field of the
+The segment size is given by the \HFNsegmentselectorsize{} field of the
 header, and the address size is given by the \addttindex{address\_size}
-field of the header. If the \addttindex{segment\_size} field in the header
+field of the header. If the \HFNsegmentselectorsize{} field in the header
 is zero, the entries consist only of an addresses.
 
 The \DWATaddrbase{} attribute points to the first entry
@@ -3299,9 +3461,9 @@ Section \refersec{datarep:32bitand64bitdwarfformats}).
 
 \needlines{4}
 \item  \texttt{version} (\HFTuhalf) \\
+\addtoindexx{version number!range list table}
 A 2-byte version identifier containing the value
-\versiondotdebugranges{} 
-(see Appendix \refersec{app:dwarfsectionversionnumbersinformative}).
+\versiondotdebugranges{}. 
 
 \needlines{4}
 \item  \texttt{address\_size} (\HFTubyte) \\
@@ -3311,7 +3473,7 @@ address for segmented addressing) on the target
 system.
 
 \needlines{4}
-\item  \texttt{segment\_size} (\HFTubyte) \\
+\item  \HFNsegmentselectorsize{} (\HFTubyte) \\
 A 1-byte unsigned integer containing the size in
 bytes of a segment selector on the target system.
 \end{enumerate}
@@ -3319,16 +3481,16 @@ bytes of a segment selector on the target system.
 This header is followed by a series of range list entries as
 described in Section \refersec{chap:noncontiguousaddressranges}.
 The segment size is given by the
-\addttindex{segment\_size} field of the header, and the address size is
+\HFNsegmentselectorsize{} field of the header, and the address size is
 given by the \addttindex{address\_size} field of the header. If the
-\addttindex{segment\_size} field in the header is zero, the segment
+\HFNsegmentselectorsize{} field in the header is zero, the segment
 selector is omitted from the range list entries.
 
 The \DWATrangesbase{} attribute points to the first entry
 following the header. The entries are referenced by a byte
 offset relative to this base address.
 
-
+\needlines{12}
 \section{Location List Table}
 \label{datarep:locationlisttable}
 Each set of entries in the location list table contained in the
@@ -3348,9 +3510,9 @@ Section \refersec{datarep:32bitand64bitdwarfformats}).
 
 \needlines{4}
 \item  \texttt{version} (\HFTuhalf) \\
+\addtoindexx{version number!location list table}
 A 2-byte version identifier containing the value
-\versiondotdebugloc{} 
-(see Appendix \refersec{app:dwarfsectionversionnumbersinformative}).
+\versiondotdebugloc{}.
 
 \needlines{5}
 \item  \texttt{address\_size} (\HFTubyte) \\
@@ -3360,7 +3522,7 @@ address for segmented addressing) on the target
 system.
 
 \needlines{4}
-\item  \texttt{segment\_size} (\HFTubyte) \\
+\item  \HFNsegmentselectorsize{} (\HFTubyte) \\
 A 1-byte unsigned integer containing the size in
 bytes of a segment selector on the target system.
 \end{enumerate}
@@ -3368,10 +3530,10 @@ bytes of a segment selector on the target system.
 This header is followed by a series of location list entries as
 described in Section \refersec{chap:locationlists}.
 The segment size is given by the
-\addttindex{segment\_size} field of the header, and the address size is
-given by the \texttt{address\_size} field of the header. If the
-\addttindex{segment\_size} field in the header is zero, the segment
-selector is omitted from the range list entries.
+\HFNsegmentselectorsize{} field of the header, and the address size is
+given by the \HFNaddresssize{} field of the header. If the
+\HFNsegmentselectorsize{} field in the header is zero, the segment
+selector is omitted from range list entries.
 
 The entries are referenced by a byte offset relative to the first
 location list following this header.
@@ -3465,18 +3627,23 @@ Table \ref{tab:integerrepresentationnames}.
 \section{Type Signature Computation}
 \label{datarep:typesignaturecomputation}
 
-A type signature is computed only by the DWARF producer;
-\addtoindexx{type signature!computation}
-it is used by a DWARF consumer to resolve type references to
-the type definitions that are contained in 
-\addtoindexx{type unit}
-type units.
+A \addtoindex{type signature} is used by a DWARF consumer 
+to resolve type references to the type definitions that 
+are contained in \addtoindex{type unit}s (see Section
+\refersec{chap:typeunitentries}).
+
+\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.}
 
 \needlines{4}
 The type signature for a type T0 is formed from the 
 \MDfive{}\footnote{\livetarg{def:MDfive}{MD5} Message Digest Algorithm, 
 R.L. Rivest, RFC 1321, April 1992}
-hash of a flattened description of the type. The flattened
+digest of a flattened description of the type. The flattened
 description of the type is a byte sequence derived from the
 DWARF encoding of the type as follows:
 \begin{enumerate}[1. ]
@@ -3541,8 +3708,8 @@ code, and the attribute value.
 \DWATdiscrlist,
 \DWATdiscrvalue,
 \DWATencoding,
-\DWATenumclass,
 \DWATendianity,
+\DWATenumclass,
 \DWATexplicit,
 \DWATisoptional,
 \DWATlocation,
@@ -3580,16 +3747,30 @@ spelling of their identifier.
 
 If an implementation defines any vendor-specific attributes,
 any such attributes that are essential to the definition of
-the type should also be included at the end of the above list,
+the type are also included at the end of the above list,
 in their own alphabetical suborder.
 
 An attribute that refers to another type entry T is processed
-as follows: (a) If T is in the list V at some V[x], use the
+as follows: 
+\begin{enumerate}[ a)]
+\item
+\bb
+If 
+\eb
+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; otherwise, (b) use the letter 'T'
+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.
+\end{enumerate}
 
+\needlines{4}
 Other attribute values use the letter 'A' as the marker, and
 the value consists of the form code (encoded as an unsigned
 LEB128 value) followed by the encoding of the value according
@@ -3602,7 +3783,6 @@ to the following:
 \DWFORMexprloc,
 and \DWFORMblock.
 
-\needlines{4}
 \item If the tag in Step 3 is one of \DWTAGpointertype,
 \DWTAGreferencetype, 
 \DWTAGrvaluereferencetype,
@@ -3619,7 +3799,7 @@ entry is a \DWTAGsubprogram, the context is omitted and the
 name to be used is the ABI-specific name of the subprogram
 (for example, the mangled linker name).
 
-
+\needlines{6}
 \item If the tag in Step 3 is not one of \DWTAGpointertype,
 \DWTAGreferencetype, 
 \DWTAGrvaluereferencetype,
@@ -3668,22 +3848,22 @@ using the values defined earlier in this chapter.
 Appendix \refersec{app:typesignaturecomputationgrammar}.
 }
 
-\textit{An attribute that refers to another type entry should
-be recursively processed or replaced with the name of the
+\textit{An attribute that refers to another type entry is
+recursively processed or replaced with the name of the
 referent (in Step 4, 5 or 6). If neither treatment applies to
 an attribute that references another type entry, the entry
-that contains that attribute should not be considered for a
+that contains that attribute is not suitable for a
 separate \addtoindex{type unit}.}
 
 \textit{If a debugging information entry contains an attribute from
 the list above that would require an unsupported form, that
-entry should not be considered for a separate 
+entry is not suitable for a separate 
 \addtoindex{type unit}.}
 
-\textit{A type should be considered for a separate 
+\textit{A type is suitable for a separate 
 \addtoindex{type unit} only
 if all of the type entries that it contains or refers to in
-Steps 6 and 7 can themselves each be considered for a separate
+Steps 6 and 7 are themselves suitable for a separate
 \addtoindex{type unit}.}
 
 \needlines{4}
@@ -3694,22 +3874,23 @@ example, a constant value should be preferred to a location
 expression when possible.)
 
 Once the string S has been formed from the DWARF encoding,
-an \MDfive{} hash is computed for the string and the 
-least significant 64 bits are taken as the type signature.
+an 16-byte \MDfive{} digest is computed for the string and the 
+last eight bytes are taken as the type signature.
 
 \textit{The string S is intended to be a flattened representation of
 the type that uniquely identifies that type (that is, a different
 type is highly unlikely to produce the same string).}
 
 \needlines{6}
-\textit{A debugging information entry should not be placed in a
+\textit{A debugging information entry is not be placed in a
 separate \addtoindex{type unit}
 if any of the following apply:}
 
 \begin{itemize}
 
 \item \textit{The entry has an attribute whose value is a location
-expression, and the location expression contains a reference to
+description, and the location description 
+contains a reference to
 another debugging information entry (for example, a \DWOPcallref{}
 operator), as it is unlikely that the entry will remain
 identical across compilation units.}
@@ -3743,7 +3924,7 @@ declaration of the type.}
 \DWATdeclcolumn{} attributes are not included because they
 may vary from one source file to the next, and would prevent
 two otherwise identical type declarations from producing the
-same \MDfive{} hash.}
+same \MDfive{} digest.}
 
 \item \textit{The \DWATobjectpointer{} attribute is not included 
 because the information it provides is not necessary for the 
@@ -3756,16 +3937,50 @@ information entry are encoded by name rather than by recursively
 encoding the type to allow for cases where a complete definition 
 of the type might not be available in all compilation units.}
 
-\needlines{4}
+%\needlines{4}
 \textit{If a type definition contains the definition of a member function, 
 it cannot be moved as is into a type unit, because the member function 
 contains attributes that are unique to that compilation unit. 
-Such a type definition can be moved to a type unit by rewriting the DIE tree, 
+Such a type definition can be moved to a type unit by rewriting the 
+debugging information entry tree, 
 moving the member function declaration into a separate declaration tree, 
 and replacing the function definition in the type with a non-defining 
 declaration of the function (as if the function had been defined out of 
 line).}
 
-An example that illustrates the computation of an \MDfive{} hash may be found in 
+An example that illustrates the computation of an \MDfive{} digest may be found in 
 Appendix \refersec{app:usingtypeunits}.
 
+\section{Name Table Hash Function}
+\label{datarep:nametablehashfunction}
+The hash function used for hashing name strings in the accelerated 
+access name index table (see Section \refersec{chap:acceleratedaccess})
+is defined in \addtoindex{C} as shown in 
+Figure \referfol{fig:nametablehashfunctiondefinition}.\footnoteRR{
+This hash function is sometimes known as the 
+"\addtoindex{Bernstein hash function}" or the
+"\addtoindex{DJB hash function}"  
+(see, for example, 
+\hrefself{http://en.wikipedia.org/wiki/List\_of\_hash\_functions} or
+\hrefself{http://stackoverflow.com/questions/10696223/reason-for-5381-number-in-djb-hash-function)}.} 
+
+\begin{figure}[ht]
+\begin{lstlisting}
+
+uint32_t /* must be a 32-bit integer type */
+    hash(unsigned char *str)
+    {
+        uint32_t hash = 5381;
+        int c;
+
+        while (c = *str++)
+            hash = hash * 33 + c;
+
+        return hash;
+    }
+
+\end{lstlisting}
+\caption{Name Table Hash Function Definition}
+\label{fig:nametablehashfunctiondefinition}
+\end{figure}
+