Save current state before a LaTeX/.git software update...
authorRon Brender <ron.brender@gmail.com>
Wed, 18 May 2016 21:18:55 +0000 (17:18 -0400)
committerRon Brender <ron.brender@gmail.com>
Wed, 18 May 2016 21:18:55 +0000 (17:18 -0400)
Signed-off-by: Ron Brender <ron.brender@gmail.com>
15 files changed:
dwarf5/latexdoc/attributesbytag.tex
dwarf5/latexdoc/changesummary.tex
dwarf5/latexdoc/compression.tex
dwarf5/latexdoc/copyright.tex
dwarf5/latexdoc/datarepresentation.tex
dwarf5/latexdoc/debugsectionrelationships.tex
dwarf5/latexdoc/dwarf5.tex
dwarf5/latexdoc/examples.tex
dwarf5/latexdoc/generaldescription.tex
dwarf5/latexdoc/introduction.tex
dwarf5/latexdoc/otherdebugginginformation.tex
dwarf5/latexdoc/programscope.tex
dwarf5/latexdoc/sectionversionnumbers.tex
dwarf5/latexdoc/splitobjects.tex
dwarf5/latexdoc/typeentries.tex

index 7f5dba0..2805f7e 100644 (file)
@@ -20,38 +20,24 @@ In the following table, the following special conventions apply:
 \item The 
 \addtoindex{DECL}
 \livetarg{chap:DECL}{}
-\bb
-pseudo-attribute
-\eb
-stands for all three of the
+pseudo-attribute stands for all three of the
 \addtoindex{declaration coordinates} 
 \DWATdeclcolumn,
 \DWATdeclfile{} and 
 \DWATdeclline.
 
-\bb
 \item The \DWATdescription{} attribute can be used on any
 debugging information entry that may have a \DWATname{} attribute.
 For simplicity, this attribute is not explicitly shown.
-\eb
 
-\item The
-\bb
-\DWATsibling{} attribute can be used on any 
-debugging information entry.
-\eb
+\item The \DWATsibling{} attribute can be used on any 
+debugging information entry. 
 For simplicity, this attribute is not explicitly shown.
 
 \item The \DWATabstractorigin{} attribute can be used with
-almost any 
-\bb
-debugging information entry;
-\eb
+almost any debugging information entry; 
 the exceptions are mostly the compilation
-unit-like 
-\bb
-entries.
-\eb
+unit-like entries. 
 For simplicity, this attribute is not explicitly shown. 
 
 \end{enumerate}
@@ -183,11 +169,9 @@ For simplicity, this attribute is not explicitly shown.
 \hline
 \DWTAGcoarraytype
 &\livelink{chap:DECL}{DECL} \\*
-\bb
 &\DWATalignment{} \\*
 &\DWATbitsize{} \\*
 &\DWATbytesize{} \\*
-\eb
 &\DWATname{} \\*
 %\DWATdescription{} \\*
 &\DWATtype{} \\
@@ -358,9 +342,7 @@ For simplicity, this attribute is not explicitly shown.
 \DWTAGgenericsubrange
 &\livelink{chap:DECL}{DECL}  \\*
 &\DWATaccessibility{}  \\*
-\bb
 &\DWATalignment{} \\*
-\eb
 &\DWATallocated{}  \\*
 &\DWATassociated{}  \\*
 &\DWATbitsize{}  \\*
@@ -887,9 +869,7 @@ For simplicity, this attribute is not explicitly shown.
 
 \hline
 \DWTAGwithstmt{}
-\bb
 &\livelink{chap:DECL}{DECL}   \\*
-\eb
 &\DWATaccessibility{}    \\*
 &\DWATaddressclass{}    \\*
 &\DWATdeclaration{}    \\*
index f31860a..5a790c9 100644 (file)
@@ -15,6 +15,7 @@ This change summary is included only in draft versions of this document.
 \begin{longtable}{ll}
 \textbf{Date}  & \textbf{Issue Incorporated or Other Change}   \\ \hline       \\
 \endhead
+4/15-5/2/2016   & Remove change bars, Other miscellaneous editorial work \\
 3/4-7/2016      & Editorial work from 3/4/2016 editorial review \\
 2/8/2016        & More editorial work from 1/29/2016 editorial review \\
 1/29-30/2016    & Editorial work from 1/29/2016 editorial review \\
index 1e85588..6471580 100644 (file)
@@ -1280,9 +1280,7 @@ attribute
     : 'T' at-code signature              // Recursive type
 children                 //  Step 7
     : child children
-\end{alltt}\bb\vspace{-0.8\baselineskip}\begin{alltt}
     : '\textbackslash{}0'
-\end{alltt}\eb\vspace{-0.8\baselineskip}\begin{alltt}
 child
     : 'S' tag-code string
     : signature
@@ -1295,7 +1293,6 @@ form-encoded-value
     : \DWFORMflag value \addtoindexx{flag class}
     : \DWFORMstring string \addtoindexx{string class}
     : \DWFORMblock \nolink{block} \addtoindexx{block class}
-\end{alltt}\bb\vspace{-0.8\baselineskip}\begin{alltt}
 \DWFORMstring \addtoindexx{string class}
     : '\textbackslash{}x08'
 \DWFORMblock  \addtoindexx{block class}
@@ -1304,7 +1301,6 @@ form-encoded-value
     : '\textbackslash{}x0c'
 \DWFORMsdata \addtoindexx{constant class}
     : '\textbackslash{}x0d'
-\end{alltt}\eb\vspace{-0.8\baselineskip}\begin{alltt}
 value
     : <SLEB128>
 \nolink{block}
index 9fca3fb..1946154 100644 (file)
@@ -7,9 +7,7 @@
 \begin{center}
 \dwf, Version 5
 
-\bb
 Copyright~\copyright~2005, 2010, 2016 \dwf\ Committee
-\eb
 \end{center}
 
 \vspace{4ex}
index cca0e25..2007ff7 100644 (file)
@@ -27,18 +27,13 @@ appropriate prefix
 \DWCClouserMARK{}\DWCChiuserMARK{}DW\_CC, 
 \DWCFAlouserMARK{}\DWCFAhiuserMARK{}DW\_CFA, 
 \DWENDlouserMARK{}\DWENDhiuserMARK{}DW\_END, 
-\bb
 \DWIDXlouserMARK{}\DWIDXhiuserMARK{}DW\_IDX, 
-\eb
 \DWLANGlouserMARK{}\DWLANGhiuserMARK{}DW\_LANG, 
-\bb
 \DWLNCTlouserMARK{}\DWLNCThiuserMARK{}DW\_LNCT, 
-\eb
 \DWLNElouserMARK{}\DWLNEhiuserMARK{}DW\_LNE, 
 \DWMACROlouserMARK{}\DWMACROhiuserMARK{}DW\_MACRO, 
 \DWOPlouserMARK{}\DWOPhiuserMARK{}DW\_OP or 
 \DWTAGlouserMARK{}\DWTAGhiuserMARK{}DW\_TAG) 
-\bbeb 
 followed by \_lo\_user or \_hi\_user. 
 Values in the  range between \textit{prefix}\_lo\_user 
 and \textit{prefix}\_hi\_user inclusive,
@@ -47,12 +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 
-\bb
-debugging information entry
-\eb
-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
@@ -60,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
@@ -230,12 +220,9 @@ space of the program and require relocation.
 
 \needlines{4}
 \textit{Note that operands of classes 
-\bbeb
 \CLASSconstant{} and 
 \CLASSflag{} do not require relocation. Attribute operands that use 
-\bb
 forms \DWFORMstring{},
-\eb 
 \DWFORMrefone, \DWFORMreftwo, \DWFORMreffour, \DWFORMrefeight, or
 \DWFORMrefudata{} also do not need relocation.}
 
@@ -247,10 +234,8 @@ information such that the majority of the debugging
 information can remain in individual object files without
 being processed by the linker. 
 
-\bb
 \textit{This reduces link time by reducing the amount of information
 the linker must process.}
-\eb
 
 \needlines{6}
 \subsubsection{First Partition (with Skeleton Unit)}
@@ -291,12 +276,9 @@ 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 
-\bbeb
 DWARF object file that contains the second partition.
 
-\bb
 \subsubsection{Second Partition (Unlinked or in a \texttt{.dwo} File)}
-\eb
 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
@@ -311,24 +293,23 @@ The full compilation unit, in the \dotdebuginfodwo{} section.
 The full compilation unit entry includes a \DWATdwoid{} 
 attribute whose form and value is the same as that of the \DWATdwoid{} 
 attribute of the associated skeleton unit.
+
 \needlines{4}
 \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 
-\bb
-descriptions 
-\eb
-may similarly do so using the \DWOPaddrx{} and
+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.
 
 \item
@@ -354,10 +335,7 @@ section.
 
 Except where noted otherwise, all references in this document
 to a debugging information section (for example, \dotdebuginfo),
-\bb
-apply 
-\eb
-also to the corresponding split DWARF section (for example,
+apply also to the corresponding split DWARF section (for example,
 \dotdebuginfodwo).
 
 \needlines{4}
@@ -371,7 +349,6 @@ references within or between sections are not possible.
 The relocated addresses in the debugging information for an
 executable object are virtual addresses.
 
-\bb
 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
@@ -385,8 +362,6 @@ depending on the class allowed by a particular attribute of a
 debugging information entry, as shown in 
 Table \refersec{tab:attributeencodings}.)
 
-\eb
-
 \needlines{6}
 \subsection{Shared Object Files}
 \label{datarep:sharedobjectfiles}
@@ -402,12 +377,10 @@ 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.}
 
-\bb
 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.
-\eb
 
 \subsection{DWARF Package Files}
 \label{datarep:dwarfpackagefiles}
@@ -512,7 +485,6 @@ The index section header contains the following fields:
 A version number.
 \addtoindexx{version number!CU index information} 
 \addtoindexx{version number!TU index information}
-\bbeb 
 This number is specific to the CU and TU index information
 and is independent of the DWARF version number.
 
@@ -520,11 +492,9 @@ The version number is \versiondotdebugcuindex.
 
 \item \textit{padding} (\HFTuhalf) \\
 Reserved to DWARF (must be zero).
-\bb
 \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.
-\eb
 
 \item \texttt{unit\_count} (\HFTuword) \\
 The number of compilation units or type units in the index.
@@ -581,9 +551,7 @@ 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 4-byte words, 
 %(using the byte order of the application binary),
-\bb 
 with $N$ sections and $U + 1$
-\eb
 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
@@ -591,9 +559,7 @@ 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}.
 
-\bb
 \textit{Not all sections listed in the table need be included.}
-\eb
 
 \needlines{12}
 \begin{centering}
@@ -638,17 +604,12 @@ 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 4-byte
-words, with 
-\bb
-$N$ 
-\eb
+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).
 
-\bb
 For an example, see Figure \refersec{fig:examplecuindexsection}.
-\eb
 
 \subsection{DWARF Supplementary Object Files}
 \label{datarep:dwarfsupplemetaryobjectfiles}
@@ -658,17 +619,12 @@ 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 
-\bb
-then be
-\eb
-referenced
+then be referenced
 from the debugging information of each of those executable or 
 shared object files.
 
-\bb
 This facilitates distribution of separate consolidated debug files in
 a simple manner.
-\eb
 
 \needlines{4}
 A DWARF \addtoindex{supplementary object file} is itself an object file, 
@@ -686,7 +642,6 @@ The \dotdebugsup{} section contains:
 \addttindexx{version}
 A 2-byte unsigned integer representing the version of the DWARF
 information for the compilation unit. 
-\bbeb
 
 The value in this field is \versiondotdebugsup.
 
@@ -714,21 +669,15 @@ this value can be 0 if no checksum is provided.
 
 \item \texttt{sup\_checksum} (array of \HFTubyte) \\
 \addttindexx{sup\_checksum}
-\bb
 An implementation-defined integer constant value that
 provides unique identification of the supplementary file.
-\eb
 
 \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 
-\bb
-descriptions 
-\eb
-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 file compilation units can use
@@ -759,10 +708,7 @@ the executable or shared object file.
 \hypertarget{datarep:xxbitdwffmt}{}
 \addtoindexx{32-bit DWARF format}
 \addtoindexx{64-bit DWARF format}
-There are two 
-\bb
-closely-related DWARF
-\eb
+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
@@ -774,12 +720,10 @@ 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.
 
-\bb
 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).
-\eb
 
 The differences between the 32- and 64-bit DWARF formats are
 detailed in the following:
@@ -879,7 +823,6 @@ in the 64-bit DWARF format, it is a 8-byte unsigned integer.
 
 \needlines{4}
 \item In the body of the \dotdebugstroffsets{} 
-\bbeb
 sections, the size of entries in the body depend on the DWARF
 format as follows: in the 32-bit DWARF format, entries are 4-byte
 unsigned integer values; in the 64-bit DWARF format, they are
@@ -987,9 +930,7 @@ enumeration are shown in Table \refersec{tab:unitheaderunitkindencodings}.
 \end{centering}
 
 \needlines{5}
-\bb
 \subsubsection{Compilation and Partial Unit Headers}
-\eb
 \label{datarep:compilationunitheader}
 \begin{enumerate}[1. ]
 
@@ -1012,14 +953,11 @@ integer that gives the actual length
 \addtoindexx{version number!compilation unit}
 A 2-byte unsigned integer representing the version of the
 DWARF information for the compilation unit.
-\bbeb
  
 The value in this field is \versiondotdebuginfo.
 
-\bb
 \textit{See also Appendix \refersec{app:dwarfsectionversionnumbersinformative}
 for a summary of all version numbers that apply to DWARF sections.}
-\eb
 
 \needlines{4}
 \item \texttt{unit\_type} (\HFTubyte) \\
@@ -1033,7 +971,6 @@ The value of this field is
 \textit{This field is new in \DWARFVersionV.}
 
 \needlines{4}
-\bb
 \item \texttt{address\_size} (\HFTubyte) \\
 \addttindexx{address\_size}
 A 1-byte unsigned integer representing the size in bytes of
@@ -1041,7 +978,6 @@ 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.
-\eb
 
 \item \HFNdebugabbrevoffset{} (\livelink{datarep:sectionoffsetlength}{section offset}) \\
 A 
@@ -1054,8 +990,6 @@ the \thirtytwobitdwarfformat, this is a 4-byte unsigned length;
 in the \sixtyfourbitdwarfformat, this is an 8-byte unsigned length
 (see Section \refersec{datarep:32bitand64bitdwarfformats}).
 
-\bbpareb
-
 \end{enumerate}
 
 \needlines{8}
@@ -1086,7 +1020,6 @@ consists of the 4-byte value \wffffffff followed by an
 \addtoindexx{version number!type unit}
 A 2-byte unsigned integer representing the version of the
 DWARF information for the type unit.
-\bbeb
  
 The value in this field is \versiondotdebuginfo.
 
@@ -1099,7 +1032,6 @@ The value of this field is \DWUTtype{} for a type unit
 \textit{This field is new in \DWARFVersionV.}
 
 \needlines{4}
-\bb
 \item \texttt{address\_size} (\HFTubyte) \\
 \addttindexx{address\_size}
 A 1-byte unsigned integer representing the size 
@@ -1109,7 +1041,6 @@ 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.
-\eb
 
 \item \HFNdebugabbrevoffset{} (\livelink{datarep:sectionoffsetlength}{section offset}) \\
 A 
@@ -1122,8 +1053,6 @@ the \thirtytwobitdwarfformat, this is a 4-byte unsigned length;
 in the \sixtyfourbitdwarfformat, this is an 8-byte unsigned length
 (see Section \refersec{datarep:32bitand64bitdwarfformats}).
 
-\bbpareb
-
 \item \texttt{type\_signature} (8-byte unsigned integer) \\
 \addttindexx{type\_signature}
 \addtoindexx{type signature}
@@ -1506,11 +1435,9 @@ Table \referfol{tab:attributeencodings}.
             \addtoindexx{friend attribute}  \\
 \DWATidentifiercase&0x42&\livelink{chap:classconstant}{constant} 
             \addtoindexx{identifier case attribute}  \\
-\bb
 \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.}
-\eb
             &\livelink{chap:classmacptr}{macptr} 
             \addtoindexx{macro information attribute (legacy)!encoding}  \\
 \DWATnamelistitem&0x44&\livelink{chap:classreference}{reference} 
@@ -2934,7 +2861,6 @@ Table \refersec{tab:discriminantdescriptorencodings}.
 \label{datarep:nameindextable}
 The \addtoindexi{version number}{version number!name index table}
 in the name index table header is \versiondotdebugnames{}.
-\bbeb
 
 The name index attributes and their encodings are listed in Table \referfol{datarep:indexattributeencodings}.
 
@@ -3017,7 +2943,6 @@ the actual length
 \item version (\HFTuhalf) \\
 A 2-byte version identifier representing the version of the
 DWARF information for the address range table.
-\bbeb
 
 This value in this field \addtoindexx{version number!address range table} is 2. 
  
@@ -3069,7 +2994,6 @@ the terminating tuple.
 
 The \addtoindexi{version number}{version number!line number information}
 in the line number program header is \versiondotdebugline{}.
-\bbeb
 
 The boolean values \doublequote{true} and \doublequote{false} 
 used by the line number information program are encoded
@@ -3172,7 +3096,6 @@ Table \refersec{tab:linenumberheaderentryformatencodings}.
 \label{datarep:macroinformation}
 The \addtoindexi{version number}{version number!macro information}
 in the macro information header is \versiondotdebugmacro{}.
-\bbeb
 
 The source line numbers and source file indices encoded in the
 macro information section are represented as 
@@ -3227,7 +3150,6 @@ value is \xffffffffffffffff.
 
 The value of the CIE \addtoindexi{version number}{version number!call frame information}
 is \versiondotdebugframe.
-\bbeb
 
 Call frame instructions are encoded in one or more bytes. The
 primary opcode is encoded in the high order two bits of
@@ -3335,12 +3257,9 @@ Section \refersec{datarep:32bitand64bitdwarfformats}).
 \addtoindexx{version number!string offsets table}
 A 2-byte version identifier containing the value
 \versiondotdebugstroffsets{}.
-\bbeb 
 
 \item \textit{padding} (\HFTuhalf) \\
-\bb
 Reserved to DWARF (must be zero).
-\eb
 \end{enumerate}
 
 This header is followed by a series of string table offsets
@@ -3374,7 +3293,6 @@ Section \refersec{datarep:32bitand64bitdwarfformats}).
 \addtoindexx{version number!address table}
 A 2-byte version identifier containing the value
 \versiondotdebugaddr{}.
-\bbeb 
 
 \needlines{4}
 \item  \texttt{address\_size} (\HFTubyte) \\
@@ -3422,7 +3340,6 @@ Section \refersec{datarep:32bitand64bitdwarfformats}).
 \addtoindexx{version number!range list table}
 A 2-byte version identifier containing the value
 \versiondotdebugranges{}. 
-\bbeb
 
 \needlines{4}
 \item  \texttt{address\_size} (\HFTubyte) \\
@@ -3472,7 +3389,6 @@ Section \refersec{datarep:32bitand64bitdwarfformats}).
 \addtoindexx{version number!location list table}
 A 2-byte version identifier containing the value
 \versiondotdebugloc{}.
-\bbeb 
 
 \needlines{5}
 \item  \texttt{address\_size} (\HFTubyte) \\
@@ -3594,6 +3510,9 @@ are contained in \addtoindex{type unit}s (see Section
 
 \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}
@@ -3708,11 +3627,24 @@ 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
@@ -3833,13 +3765,7 @@ if any of the following apply:}
 \begin{itemize}
 
 \item \textit{The entry has an attribute whose value is a location
-\bb
-description, 
-\eb
-and the location 
-\bb
-description 
-\eb
+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
@@ -3892,10 +3818,7 @@ of the type might not be available in all compilation units.}
 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 
-\bb
-debugging information entry
-\eb
-tree, 
+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 
@@ -3911,16 +3834,13 @@ 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 
-\bb
 "\addtoindex{Bernstein hash function}" or the
-\eb
 "\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]
-\bb
 \begin{lstlisting}
 
 uint32_t /* must be a 32-bit integer type */
@@ -3936,7 +3856,6 @@ uint32_t /* must be a 32-bit integer type */
     }
 
 \end{lstlisting}
-\eb
 \caption{Name Table Hash Function Definition}
 \label{fig:nametablehashfunctiondefinition}
 \end{figure}
index 5d90483..38492df 100644 (file)
@@ -6,7 +6,6 @@ cases, information in one section refers to information in one
 or more of the others. These relationships are illustrated by 
 the diagrams and associated notes on the following pages.
 
-\bb
 In the figures, a section is shown as a shaded oval with the
 name of the section inside. References from one section to
 another are shown by an arrow. In the first figure, the arrow
@@ -15,7 +14,6 @@ of the construct (such as an attribute or form) that encodes
 the reference. In the second figure, this box is left out
 for reasons of space in favor of a label annotation that is
 explained in the subsequent notes.
-\eb
 
 \section{Normal DWARF Section Relationships}
 Figure \referfol{fig:debugsectionrelationships} illustrates
@@ -51,7 +49,7 @@ or shareable file and a related \addtoindex{supplementary object file}.
                                      \dotdebuginfo\\
                                         ~
                                      \end{tabular}};
-\node(zcircs)   at (-1.8,4.0) [circ] {(s)};
+\node(zcircs)   at (-1.8,4.0) [circ] {\textit{A}};
 \node(zlinkb)   at ( 0,  1.5) [link] {To compilation unit~~(b)};
 \node(zsectpub) at ( 0,-0.25) [sect] {\begin{tabular}{c} 
                                      \dotdebugnames  
@@ -158,8 +156,8 @@ or shareable file and a related \addtoindex{supplementary object file}.
                                         \DWMACROimport \\
                                         (q)
                                         \end{tabular}};
-\node(zcircsp)  at (17.4,  4.0) [circ]  {(s)'};
-\node(zlinkx)   at (15.6,  2.0) [link]  {\DWFORMlinestrp~(r)};
+\node(zcircsp)  at (17.4,  4.0) [circ]  {\textit{A}};
+\node(zlinkx)   at (15.6,  2.0) [link]  {\DWFORMlinestrp~(r, s)};
 \node(zsectlns) at (15.6,-0.25) [sect]  {\dotdebuglinestr};
              
              
index 2e55559..eca4080 100644 (file)
@@ -3,7 +3,7 @@
 % 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}{March 7, 2016}
+\newcommand{\docdate}{May 2, 2016}
 %
 \usepackage{ifthen}
     \newcommand{\ifthen}[2]{\ifthenelse{#1}{#2}{}}
@@ -273,9 +273,7 @@ escapeinside={\%*}{*)}     % if you want to add a comment within your code
 \url{http://www.dwarfstd.org}
 \\
 \vspace{2cm}
-\bb
 {\Large \textbf{\docdate}}
-\eb
 \\
 \ifthenelse{\boolean{isdraft}}{
        \vspace{2cm}
index cbbc86f..311f54c 100644 (file)
@@ -269,7 +269,7 @@ examples illustrate their behavior graphically.}
 Following are examples of DWARF operations used to form location descriptions:
 
 \newcommand{\descriptionitemnl}[1]
-        {\vspace{0.5\baselineskip}\item[#1]\mbox{}\\\vspace{0.5\baselineskip}}
+        {\vspace{0.3\baselineskip}\item[#1]\mbox{}\\\vspace{0.5\baselineskip}}
 \begin{description}
 \descriptionitemnl{\DWOPregthree}
 The value is in register 3.
@@ -324,7 +324,6 @@ value consists of two parts, given in memory address order: the 4 byte
 value 1 followed by the four byte value computed from the sum of the
 contents of r3 and r4.
 
-\bb
 \descriptionitemnl{\DWOPentryvalue{} 1 \DWOPregone{} }
 The value register 1 contained upon entering the current subprogram is 
 pushed on the stack.
@@ -340,26 +339,37 @@ The value register 1 contained upon entering the current subprogram
 \doublequote{contents} of an otherwise anonymous location.
 
 This and the previous location description are equivalent;
-the previous one is shorter, however.
-\eb
+the previous one is shorter, however. 
 
 %FIXME: The following gets an undefined control sequence error for reasons unknown... 
 %\descriptionitemnl{\DWOPentryvalue{} 1 \DWOPregthirtyone{} \DWOPregone{} \DWOPadd{} \DWOPstackvalue }
 %The value register 31 had upon entering the current subprogram
 %plus the value register 1 currently has.
 
+% Is the following example really interesting enough (not just complicated) to keep?
+\ifthen{\boolean{true}}{
 \descriptionitemnl{\DWOPentryvalue{} 3 \DWOPbregfour{} 16 \DWOPderef{} \DWOPstackvalue }
 %FIXME: similar undefined as just above
 %\descriptionitemnl{\DWOPentryvalue{} 6 \DWOPentryvalue{} 1 \DWOPregfour{} \DWOPplusuconst{} 16 \DWOPderef{} \DWOPstackvalue }
 Add 16 to the value register 4 had upon entering the current subprogram
 to form an address and then push the value of the memory location at that address.
-\bb
 This value is the
 \doublequote{contents} of an otherwise anonymous location.
+}
+
+\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}
 
-\clearpage
+%\clearpage
 \section{Aggregate Examples}
 \label{app:aggregateexamples}
 
@@ -467,6 +477,7 @@ a descriptor does have a
 \DWATdatalocation{} attribute. In
 that case the object doubles as its own descriptor.)
 
+\needlines{6}
 The \addtoindex{Fortran} derived type \texttt{array\_ptr} can now be re-described
 in C-like terms that expose some of the representation as in
 
@@ -482,10 +493,14 @@ Similarly for variable \texttt{arrayvar}:
 desc<1> arrayvar;
 \end{lstlisting}
 
-(Recall that \texttt{desc\textless 1\textgreater} 
-indicates the 1\dash dimensional version of \texttt{desc}.)
+\textit{
+\bb
+Recall that \texttt{desc\textless 1\textgreater} 
+indicates the 1\dash dimensional version of \texttt{desc}.
+\eb
+}
 
-\newpage
+%\newpage
 Finally, the following notation is useful:
 \begin{enumerate}[1. ]
 \item  sizeof(type): size in bytes of entities of the given type
@@ -730,9 +745,7 @@ illustrated in Figure \refersec{fig:FortranscalarcoarrayDWARFdescription}.
 10\$:  \DWTAGcoarraytype
           \DWATtype(reference to INTEGER)
           \DWTAGsubrangetype                ! Note omitted upper bound
-\end{alltt}\bb\vspace{-0.8\baselineskip}\begin{alltt}
           \DWATlowerbound(constant 1)       ! Can be omitted (default is 1)
-\end{alltt}\eb\vspace{-0.8\baselineskip}\begin{alltt}
 
 11\$:  \DWTAGvariable
           \DWATname("x")
@@ -764,16 +777,12 @@ illustrated in Figure \refersec{fig:FortranarraycoarrayDWARFdescription}.
           \DWATordering(\DWORDcolmajor)
           \DWATtype(reference to INTEGER)
 11\$:      \DWTAGsubrangetype
-\end{alltt}\bb\vspace{-0.8\baselineskip}\begin{alltt}
             ! \textit{DW\_AT\_lower\_bound(constant 1)}   ! Omitted (default is 1)
-\end{alltt}\eb\vspace{-0.8\baselineskip}\begin{alltt}
               \DWATupperbound(constant 10)
 
 12\$:  \DWTAGcoarraytype
           \DWATtype(reference to array type at 10\$)
-\end{alltt}\bb\vspace{-0.8\baselineskip}\begin{alltt}
 13\$:      \DWTAGsubrangetype                ! Note omitted upper \& lower bounds
-\end{alltt}\eb\vspace{-0.8\baselineskip}\begin{alltt}
 
 14$:  \DWTAGvariable
           \DWATname("x")
@@ -802,7 +811,6 @@ illustrated in Figure \referfol{fig:FortranmultidimensionalcoarrayDWARFdescripti
 \begin{figure}[ht]
 \begin{dwflisting}
 \begin{alltt}
-\end{alltt}\bb\vspace{-0.8\baselineskip}\begin{alltt}
 
 10\$:  \DWTAGarraytype                ! Note omitted lower bounds (default to 1)
           \DWATordering(\DWORDcolmajor)
@@ -821,7 +829,6 @@ illustrated in Figure \referfol{fig:FortranmultidimensionalcoarrayDWARFdescripti
 16\$:      \DWTAGsubrangetype
               \DWATupperbound(constant 3)
 17\$:      \DWTAGsubrangetype         ! Note omitted upper (\& lower) bound
-\end{alltt}\eb\vspace{-0.8\baselineskip}\begin{alltt}
 
 18\$:  \DWTAGvariable
           \DWATname("x")
@@ -1254,7 +1261,6 @@ is used to illustrate the representation of packed unaligned
 \addtoindex{bit fields}.
 
 \begin{figure}[ht]
-\bb
 \begin{lstlisting}
 TYPE T : PACKED RECORD                  { bit size is 2   }
          F5 : BOOLEAN;                  { bit offset is 0 }
@@ -1270,7 +1276,6 @@ VAR V :  PACKED RECORD
          F7 : T;                        { bit offset is 37 }
          END;
 \end{lstlisting}
-\eb
 \caption{Packed record example: source fragment}
 \label{fig:packedrecordexamplesourcefragment}
 \end{figure}
@@ -1540,9 +1545,7 @@ int Foo::myfunc(int a)
           ...
 6\$:   \DWTAGnamespace
           ! no \DWATname attribute
-\end{alltt}\bb\vspace{-0.8\baselineskip}\begin{alltt}
           \DWATexportsymbols              ! Implied by C++, but can be explicit
-\end{alltt}\eb\vspace{-0.8\baselineskip}\begin{alltt}
           \DWTAGvariable
               \DWATname("i")
               \DWATtype(reference to 1\$)
@@ -1580,7 +1583,6 @@ int Foo::myfunc(int a)
 \begin{figure}
 \figurepart{2}{2}
 \begin{dwflisting}
-\bb
 \begin{alltt}
 40\$:  \DWTAGnamespace
           \DWATname("Y")
@@ -1619,7 +1621,6 @@ int Foo::myfunc(int a)
           \DWAThighpc ...
           ...
 \end{alltt}
-\eb
 \end{dwflisting}
 \begin{center}
 \vspace{3mm}
@@ -1872,10 +1873,7 @@ void g() {
 \label{app:linenumberheaderexample}
 
 The information found in a \DWARFVersionIV{} line number 
-header can be encoded 
-\bb
-in a \DWARFVersionV{} header
-\eb
+header can be encoded in a \DWARFVersionV{} header
 as shown in Figure \refersec{fig:preV5LNCTusingV5}.
 
 \begin{figure}[ht]
@@ -1910,7 +1908,6 @@ as shown in Figure \refersec{fig:preV5LNCTusingV5}.
 
 \subsection{Line Number Special Opcode Example}
 \label{app:linenumberspecialopcodeexample}
-\bb
 Suppose the line number header includes the following 
 (header fields not needed are not shown):
 \begin{center}
@@ -1922,20 +1919,17 @@ Suppose the line number header includes the following
     \addttindex{maximum\_operations\_per\_instruction} & 1 \\
 \end{tabular}
 \end{center}
-\eb
 This means that
 we can use a special opcode whenever two successive rows in
 the matrix have source line numbers differing by any value
 within the range \mbox{[-3, 8]} and (because of the limited number
 of opcodes available) when the difference between addresses
 is within the range [0, 20].
-\bb
 The resulting opcode mapping is shown in
 Figure \refersec{fig:examplelinenumberspecialopcodemapping}.
 
 Note in the bottom row of the figure that not all line advances are 
 available for the maximum \addtoindex{operation advance}.
-\eb
 
 \begin{figure}[ht]
 \begin{alltt}
@@ -2010,15 +2004,12 @@ Figure \refersec{fig:linenumberprogramexamplemachinecode}.
 \end{figure}
 
 Suppose the line number program header includes the 
-\bb
 same values and resulting encoding illustrated in the 
 previous Section \refersec{app:linenumberspecialopcodeexample}.
-\eb
 
 Table \refersec{tab:linenumberprogramexampleoneencoding}
 shows one encoding of the line number program, which occupies
 12 bytes.
-\bbeb
 
 \newpage
 \begin{centering}
@@ -2035,21 +2026,17 @@ shows one encoding of the line number program, which occupies
   \hline
 \endlastfoot
 \DWLNSadvancepc&LEB128(0x239)&0x2, 0xb9, 0x04 \\
-\bb
 SPECIAL\dag~(2, 0)& & 0x12~~(18$_{10}$)  \\
 SPECIAL\dag~(2, 3)& & 0x36~~(54$_{10}$) \\
 SPECIAL\dag~(1, 8)& & 0x71~~(113$_{10}$) \\
-\eb
 SPECIAL\dag~(1, 7)& & 0x65~~(101$_{10}$) \\
 \DWLNSadvancepc&LEB128(2)&0x2, 0x2 \\
 \DWLNEendsequence{} &&0x0, 0x1, 0x1 \\
 \end{longtable}
 \end{centering}
-\bb
 \dag~The opcode notation SPECIAL(\textit{m},\textit{n}) indicates 
 the special opcode generated for a line advance of \textit{m} 
 and an operation advance of \textit{n})
-\eb
 
 Table \refersec{tab:linenumberprogramexamplealternateencoding}
 shows an alternate 
@@ -2072,14 +2059,12 @@ this encoding occupies 22 bytes.
   \hline
 \endlastfoot
 \DWLNSfixedadvancepc&0x239&0x9, 0x39, 0x2        \\
-\bb
 SPECIAL\ddag~(2, 0) && 0x12~~(18$_{10}$)        \\
 \DWLNSfixedadvancepc&0x3&0x9, 0x3, 0x0        \\
 SPECIAL\ddag~(2, 0) && 0x12~~(18$_{10}$)        \\
 \DWLNSfixedadvancepc&0x8&0x9, 0x8, 0x0        \\
 SPECIAL\ddag~(1, 0) && 0x11~~(17$_{10}$)        \\
 \DWLNSfixedadvancepc&0x7&0x9, 0x7, 0x0        \\
-\eb
 SPECIAL\ddag~(1, 0) && 0x11~~(17$_{10}$)        \\
 \DWLNSfixedadvancepc&0x2&0x9, 0x2, 0x0        \\
 \DWLNEendsequence&&0x0, 0x1, 0x1        \\
@@ -3326,9 +3311,7 @@ int main ()
               \DWATlocation(\DWOPregfive)
 21\$:      \DWTAGvariable
               \DWATname("s")
-\end{alltt}\bb\vspace{-0.8\baselineskip}\begin{alltt}
               \DWATtype(reference to S at 1\$)
-\end{alltt}\eb\vspace{-0.8\baselineskip}\begin{alltt}
               \DWATlocation(expression=
                   \DWOPbregfive(1) \DWOPstackvalue \DWOPpiece(2)
                   \DWOPbregfive(2) \DWOPstackvalue \DWOPpiece(1)
@@ -3391,7 +3374,6 @@ static inline void foo (int *p)
 
 int main ()
 \{
-\end{alltt}\bb\vspace{-0.8\baselineskip}\begin{alltt}
 label0:
     int a[2] = { 1, 2 };
     v++;
@@ -3400,7 +3382,6 @@ label1:
 label2:
     return a[0] + a[1] - 5;
 label3:
-\end{alltt}\eb\vspace{-0.8\baselineskip}\begin{alltt}
 \}
 
 \end{alltt}
@@ -3654,18 +3635,14 @@ L8:
 
 \clearpage
 The location list for variable \texttt{a} in function \texttt{fn2}
-might look like
-\bb
-the following 
+might look like the following 
 (where the notation \doublequote{\textit{Range} [\texttt{m .. n)}} 
 specifies the range of addresses from \texttt{m} through but not 
 including \texttt{n} over which the following
 location description applies):
-\eb
 
 %\begin{figure}[ht]
 \begin{dwflisting}
-\bb
 \begin{alltt}
 
     ! Before the assignment to register 0, the argument a is live in register 0
@@ -3680,7 +3657,6 @@ location description applies):
     \textit{End-of-list}
 
 \end{alltt}
-\eb
 \end{dwflisting}
 %\end{figure}
 
@@ -3688,7 +3664,6 @@ location description applies):
 Similarly, the variable \texttt{q} in \texttt{fn2} then might have this location list:
 
 \begin{dwflisting}
-\bb
 \begin{alltt}
 
     ! Before the assignment to register 0, the value of q can be computed as 
@@ -3705,7 +3680,6 @@ Similarly, the variable \texttt{q} in \texttt{fn2} then might have this location
     \textit{End-of-list}
 
 \end{alltt}
-\eb
 \end{dwflisting}
 
 \vspace*{0.7\baselineskip}
@@ -3975,8 +3949,6 @@ imported for each \texttt{\#include} directive.
 The combined size of the three macro units and their referenced
 strings is 129 bytes.
 
-\bbpareb
-
 \begin{figure}
 \begin{dwflisting}
 \begin{alltt}
@@ -4077,7 +4049,6 @@ s$2:    String: "LONGER\_MACRO 1"
 \label{fig:macroexampledsharablewarfencoding}
 \end{figure}
 
-\bb
 \needlines{4}
 A number of observations are worth mentioning:
 \begin{itemize}
@@ -4115,5 +4086,4 @@ header to allow interpretation of the file number operands in
 those commands. However, the presence of those offsets complicates
 or may preclude sharing across compilations.
 
-\end{itemize}
-\eb
\ No newline at end of file
+\end{itemize}
\ No newline at end of file
index 4022382..cc087e3 100644 (file)
@@ -836,12 +836,10 @@ one of these addresses by indexing relative to this location.
 \hypertarget{chap:classblock}{}
 \livelinki{datarep:classblock}{block}{block class}
 & An arbitrary number of uninterpreted bytes of data.
-\bb
 The number of data bytes may be implicit from context
 or explicitly specified by an initial unsigned LEB128 value
 (see Section \refersec{datarep:variablelengthdata}) 
 that precedes that number of data bytes.
-\eb
 \\
  
 \hypertarget{chap:classconstant}{}
@@ -856,11 +854,9 @@ encoded in the variable length format known as LEB128
 \livelinki{datarep:classexprloc}{exprloc}{exprloc class}
 &A DWARF expression for a value or a location in the 
 address space of the described program.
-\bb
 A leading unsigned LEB128 value 
 (see Section \refersec{datarep:variablelengthdata})
 specifies the number of bytes in the expression.
-\eb
 \\
 
 \hypertarget{chap:classflag}{}
@@ -1664,7 +1660,10 @@ The \DWOPnopTARG{} operation is a place holder. It has no effect
 on the location stack or any of its values.
 
 \itembfnl{\DWOPentryvalueNAME}
-The \DWOPentryvalueTARG{} operation pushes a value that had a known location
+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 
@@ -1680,7 +1679,6 @@ in exactly one value being pushed on the DWARF stack when completed.
 
 \DWOPpushobjectaddress{} is not meaningful inside of this DWARF operation.
 
-\bb
 \textit{
 The values needed to evaluate \DWOPentryvalueNAME{} could be obtained in
 several ways. The consumer could suspend execution on entry to the
@@ -1692,7 +1690,6 @@ values.  Or, when evaluating \DWOPentryvalueNAME{}, the consumer could
 (see Section \refersec{chap:callframeinformation}) 
 to recover register values that might have been clobbered since the
 subprogram entry point.}
-\eb
 
 \end{enumerate}
 
@@ -1926,10 +1923,7 @@ containing the \DWOPimplicitpointer{} operation.}
 
 \end{enumerate}
 
-\textit{DWARF location 
-\bb
-descriptions 
-\eb
+\textit{DWARF location descriptions 
 are intended to yield the \textbf{location}
 of a value rather than the value itself. An optimizing compiler
 may perform a number of code transformations where it becomes
@@ -2023,10 +2017,7 @@ forms are otherwise equivalent.
 \label{chap:locationlistsinnonsplitobjects}
 Location lists 
 \addtoindexx{location list}
-are used in place of location 
-\bb
-descriptions
-\eb
+are used in place of location descriptions
 whenever the object whose location is being described
 can change location during its lifetime. 
 Location lists
@@ -2633,11 +2624,9 @@ Section \referfol{chap:linkagenames} regarding the use of
 \addtoindex{mangled names}.
 Sequences of multiple whitespace characters may be compressed.}
 
-\bb
 \textit{For additional discussion, see the Best Practices section 
 of the DWARF Wiki 
 (\url{http://wiki.dwarfstd.org/index.php?title=Best_Practices}.)}
-\eb
 
 \section{Data Locations and DWARF Procedures}
 \hypertarget{chap:DWATlocationdataobjectlocation}{}
@@ -2908,11 +2897,8 @@ yields the value of the attribute.
 in the program that are artificial, or which otherwise have a 
 \doublequote{name} that is not a valid identifier in the
 programming language. 
-\bb
 This attribute provides a means for the producer to indicate
-the purpose or usage of the containing debugging information entry.
-\eb
-}
+the purpose or usage of the containing debugging infor}
 
 Generally, any debugging information entry that 
 has,\hypertarget{chap:DWATdescriptionartificialnameordescription}{}
@@ -2922,13 +2908,8 @@ or may have, a \DWATname{} attribute, may also have a
 null-terminated string providing a description of the entity.
 
 \textit{It is expected that a debugger will 
-\bbeb
-display these
-descriptions as part of 
-\bb
-displaying other properties of an entity.
-\eb
-}
+display these descriptions as part of 
+displaying other properties of an entity.}
 
 \needlines{4}
 \section{Byte and Bit Sizes}
index 2c4801b..6a595d8 100644 (file)
@@ -119,7 +119,7 @@ general application.  For these, DWARF has a description
 designed to meet the language requirements, although, to the 
 extent possible, an effort is made to generalize the attribute. 
 An example of this is the \DWTAGconditionNAME{} 
-\bb debugging information entry,\eb 
+debugging information entry, 
 used to describe \addtoindex{COBOL} level 88 conditions, which 
 is described in abstract terms rather than COBOL-specific terms.  
 Conceivably, this TAG might be used with a different language 
@@ -262,21 +262,36 @@ 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 require that a particular producer describe any particular source
-construct or aspect of the source to object mapping; nor does it specify
-how a particular consumer should make use of this description.  DWARF is
-permissive, allowing different producers to generate different
-descriptions for the same source to object conversion.  As long as the
-content of the generated DWARF description follows this specification,
-the producer is conforming to the specification; as long as the consumer
-follows this specification when interpreting the generated description,
-the consumer is conforming to the specification.
-
+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
+than another, it may describe features in a different order (unless the 
+standard explicitly requires a particular order), or it may use
+different abbreviations or compression methods.  Similarly, DWARF does not
+specify exactly what a particular consumer should do with each part of the
+description, although we believe that the potential uses for each description
+should be evident.
+
+DWARF is permissive, allowing different producers to generate different
+descriptions for the same source to object conversion, and permitting
+different consumers to provide more or less functionality or information
+to the user.  This may result in debugging information being larger or
+smaller, compilers or debuggers which are faster or slower, and more or
+less functional.  These are described as differences in "Quality of
+Implementation".
+
+Each producer conforming to the DWARF standard must follow the format and
+meaning as specified in the standard.  As long as the DWARF description
+generated follows this specification, the producer is generating valid DWARF.
 For example, DWARF allows a producer to identify the end of a function
-prologue in the Line Information so that a debugger can stop at this
-location. A producer which does this is generating valid DWARF, as is
-another which doesn't.
+prologue in the Line Information so that a debugger can stop at this location.
+A producer which does this is generating valid DWARF, as is another which
+doesn't.  As another example, one producer may generate descriptions
+for variables which are moved from memory to a register in a certain range,
+while another may only describe the variable's location in memory.  Both are
+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}
index 6b57826..05b0287 100644 (file)
@@ -104,48 +104,32 @@ the entire load module.
 \subsubsection{Contents of the Name Index}
 \label{chap:contentsofthenameindex}
 The name index must contain an entry for each 
-\bb
-debugging information entry
-\eb
-that defines a
-named subprogram, label, variable, type, or namespace, subject to
-the following rules:
+debugging information entry that defines a
+named subprogram, label, variable, type, or namespace, 
+subject to the following rules:
 \begin{itemize}
 
 \item All non-defining declarations (that is, 
-      \bb
-      debugging information entries
-      \eb
-      with a
+      debugging information entries with a
       \DWATdeclaration{} attribute) are excluded.
 
-\item \DWTAGnamespace{} 
-      \bb
-      debugging information entries
-      \eb
+\item \DWTAGnamespace{} debugging information entries 
       without a \DWATname{} attribute are
-      included with the name \doublequote{\texttt{(anonymous namespace)}}.
+      included with the name 
+      \doublequote{\texttt{(anonymous namespace)}}.
 
-\item All other 
-      \bb
-      debugging information entries
-      \eb
+\item All other debugging information entries 
       without a \DWATname{} attribute are excluded.
 
 \item \DWTAGsubprogram{}, \DWTAGinlinedsubroutine{}, and
-      \DWTAGlabel{} 
-      \bb
-      debugging information entries
-      \eb
+      \DWTAGlabel{} debugging information entries 
       without an address attribute (\DWATlowpc{},
-      \DWAThighpc{}, \DWATranges{}, or \DWATentrypc{}) are excluded.
-
-\item \DWTAGvariable{} 
-      \bb
-      debugging information entries
-      \eb
-      with a \DWATlocation{} attribute that
-      includes a \DWOPaddr{} or \DWOPformtlsaddress{} operator are
+      \DWAThighpc{}, \DWATranges{}, or \DWATentrypc{}) 
+      are excluded.
+
+\item \DWTAGvariable{} debugging information entries 
+      with a \DWATlocation{} attribute that includes a 
+      \DWOPaddr{} or \DWOPformtlsaddress{} operator are
       included; otherwise, they are excluded.
 
 \item If a subprogram or inlined subroutine is included, and has a
@@ -155,28 +139,16 @@ the following rules:
 \end{itemize}
 
 For the purposes of determining whether a 
-\bb
-debugging information entry
-\eb
-has a particular
+debugging information entry has a particular
 attribute (such as \DWATname{}), if 
-\bb
-debugging information entry
-\eb
-$A$ has a \DWATspecification{}
+debugging information entry $A$ has a \DWATspecification{}
 or \DWATabstractorigin{} attribute pointing to another 
-\bb
-debugging information entry
-\eb
-$B$, any
-attributes of \bbeb $B$ are considered to be part of \bbeb $A$.
+debugging information entry $B$, any
+attributes of $B$ are considered to be part of $A$.
 
 \textit{The intent of the above rules is to provide the consumer with
 some assurance that looking up an unqualified name in the index
-will yield all relevant 
-\bb
-debugging information entries
-\eb
+will yield all relevant debugging information entries
 that provide a defining declaration
 at global scope for that name.}
 
@@ -188,15 +160,14 @@ below.}
 \needlines{4}
 \subsubsection{Structure of the Name Index}
 \label{chap:structureofthenametindex}
-Logically, the name index can be viewed as a list of names, with a
-list of index entries for each name. Each index entry corresponds to a
-\bb
-debugging information entry
-\eb
+Logically, the name index can be viewed as a list of names, 
+with a list of index entries for each name. Each index entry 
+corresponds to a debugging information entry 
 that matches the criteria given in the previous section. For
-example, if one compilation unit has a function named \texttt{fred} and
-another has a struct named \texttt{fred}, a lookup for \doublequote{fred} will find the
-list containing those two index entries.
+example, if one compilation unit has a function named \texttt{fred} 
+and another has a struct named \texttt{fred}, a lookup for 
+\doublequote{fred} will find the list containing those two index 
+entries.
 
 The index section contains eight individual parts, as illustrated in 
 Figure \referfol{fig:nameindexlayoutpart1}.
@@ -547,7 +518,6 @@ Figure~\ref{fig:nameindexlayoutpart1}: Name Index Layout \textit{(concluded)}
 \end{figure}
 
 The formats of the header and the hash lookup table are described
-\bbeb
 in Section \refersec{chap:datarepresentationofthenameindex}.
 
 The list of CUs and the list of local TUs are each an array of
@@ -600,31 +570,22 @@ The standard attributes are:
 \item Type Unit (TU), a reference to an entry in the list of local
     or foreign TUs.
 
-\item
-    \bb
-    Debugging information entry
-    \eb
-    offset within the CU or TU.
-
-\item Parent 
-    \bb
-    debugging information entry,
-    \eb
+\item Debugging information entry offset within the CU or TU.
+
+\item Parent debugging information entry, 
     a reference to the index entry for the parent.
     This is represented as the offset of the entry relative to
     the start of the entry pool.
 
 \item Type hash, an 8-byte hash of the type declaration.
+
 \end{itemize}
 
 \needlines{6}
-It is possible that an indexed 
-\bb
-debugging information entry
-\eb
+It is possible that an indexed debugging information entry
 has a parent that is not
-indexed (for example, if its parent does not have a name attribute). In
-such a case, a parent attribute may point to a nameless index
+indexed (for example, if its parent does not have a name attribute). 
+In such a case, a parent attribute may point to a nameless index
 entry (that is, one that cannot be reached from any entry in the
 name table), or it may point to the nearest ancestor that does
 have an index entry.
@@ -709,17 +670,12 @@ not including the length field itself.
 
 \item \texttt{version} (\HFTuhalf) \\
 A version number\addtoindexx{version number!name index table} 
-\bb
-(see Section \refersec{datarep:nameindextable}).
-\eb 
+(see Section \refersec{datarep:nameindextable}). 
 This number is specific to the name index table and is
 independent of the DWARF version number.
 
 \item \textit{padding} (\HFTuhalf) \\
-Reserved to DWARF
-\bb
-(must be zero).
-\eb
+Reserved to DWARF (must be zero). 
 
 \item \texttt{comp\_unit\_count} (\HFTuword) \\
 The number of CUs in the CU list.
@@ -753,17 +709,19 @@ contents and interpretation are not specified here. The
 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}
+
 \end{enumerate}
 
 \needlines{4}
 \subsubsubsection{List of CUs}
 The list of CUs immediately follows the header. Each entry in the 
-list is an offset 
-\bbeb 
-of the corresponding compilation unit
-\bb
+list is an offset of the corresponding compilation unit
 in the \dotdebuginfo{} section.
-\eb
 In the DWARF-32 format, a section offset is 4 bytes, 
 while in the DWARF-64 format, a section offset is 8 bytes.
 
@@ -773,11 +731,8 @@ There must be at least one CU.
 \needlines{4}
 \subsubsubsection{List of Local TUs}
 The list of local TUs immediately follows the list of CUs. Each 
-entry in the list is an offset 
-\bb
-of the corresponding type unit
-in the \dotdebuginfo{} section.
-\eb
+entry in the list is an offset of the corresponding type unit
+in the \dotdebuginfo{} section. 
 In the DWARF-32 format, a section offset is 4 bytes, 
 while in the DWARF-64 format, a section offset is 8 bytes.
 
@@ -805,9 +760,7 @@ contains 4-byte unsigned integers.
 \needlines{4}
 Symbols are entered into the hash table by first computing a hash
 value from the symbol name. The hash is computed 
-\bb
-using the "DJB" hash function\addtoindexx{DJB hash function}
-\eb
+using the "DJB" hash function\addtoindexx{DJB hash function} 
 described in Section \refersec{datarep:nametablehashfunction}.
 Given a hash value for the symbol,
 the symbol is entered into a bucket whose index is the hash value
@@ -848,12 +801,10 @@ indexed starting at 1 (to match the hashes array).
 The number of rows in the name table is given by \texttt{name\_count}.
 
 If there is a hash lookup table, the 
-\bbeb
 row number of an entry in the name table must
 match the row number of its corresponding entry in the hashes array.
 
 If there is no hash lookup table, there is no ordering 
-\bbeb
 requirement for the name table.
 
 \needlines{6}
@@ -900,7 +851,6 @@ Table \referfol{tab:indexattributeencodings}.
 \DWIDXdieoffsetTARG   & Offset of DIE within CU or TU                \\
 \DWIDXparentTARG      & Index of name \mbox{table} entry for parent  \\
 \DWIDXtypehashTARG    & Hash of type \mbox{declaration}              \\
-\bbeb
 \end{longtable}
 \end{centering}
 
@@ -951,9 +901,7 @@ not including the length field itself.
 
 \item \texttt{version} (\HFTuhalf) \\
 A version number\addtoindexx{version number!address lookup table}
-\bb 
 (see Section \refersec{datarep:addrssrangetable}). 
-\eb
 This number is specific to the address lookup table and is
 independent of the DWARF version number.
 
@@ -1488,19 +1436,14 @@ of the directory entries in order, beginning with 0.
 represented in the directories field and a directory index
 of 0 implicitly referred to that directory as found in the
 \DWATcompdir{} attribute of the compilation unit 
-\bb
-debugging information entry.
-\eb
+debugging information entry. 
 In \DWARFVersionV, the current directory is explicitly present
 in the directories field. This is needed to support the
 common practice of stripping all but the line number sections
 (\dotdebugline{} and \dotdebuglinestr) from an executable.}
 
 \textit{Note that if a \dotdebuglinestr{} section is present, 
-both the compilation unit 
-\bb
-debugging information entry
-\eb
+both the compilation unit debugging information entry 
 and the line number header can
 share a single copy of the current directory name string.}
 
@@ -1541,10 +1484,7 @@ a declaration coordinate or a macro file inclusion.
 The first entry in the sequence is the primary source file 
 whose file name exactly matches that given in the 
 \DWATname{} attribute in the compilation unit 
-\bb
 debugging information entry.
-\eb
-
    
 The line number program references file names in this 
 sequence beginning with 0, and uses those numbers instead 
@@ -1558,10 +1498,7 @@ the common practice of stripping all but the line number sections
 (\dotdebugline{} and \dotdebuglinestr) from an executable.}
 
 \textit{Note that if a \dotdebuglinestr{} section is present, 
-both the compilation unit 
-\bb
-debugging information entry
-\eb
+both the compilation unit debugging information entry 
 and the line number header can
 share a single copy of the current file name string.}
 
@@ -2031,11 +1968,9 @@ inclusion entries.  Each entry consists of an opcode followed by
 zero or more operands. Each macro unit ends with an entry
 containing an opcode of 0.
 
-\bb
 In all macro information entries,
 the line number of the entry is encoded as an
 unsigned LEB128 integer.
-\eb
 
 \needlines{6}
 \subsection{Macro Information Header}
@@ -2110,12 +2045,10 @@ order in which the directives were processed by the
 compiler (after taking into account the effect of the
 macro import directives).
 
-\bb
 \textit{The source file in which a macro information entry occurs
 can be derived by interpreting the sequence of entries from the
 beginning of the \dotdebugmacro{} section. \DWMACROstartfile{} and 
-\DWMACROendfile{} indicate changes in the containing file.}
-\eb
+\DWMACROendfile{} indicate changes in the containing file.} 
 
 \subsubsection{Define and Undefine Entries}
 \label{chap:defineandundefineentries}
@@ -2176,7 +2109,6 @@ The contents of the operands are described below (see Sections
 
 \end{enumerate}
 
-\bbpareb
 
 \subsubsection{Macro Define String}
 \label{chap:macrodefinestring}
@@ -2253,8 +2185,7 @@ ending of an included file.
 \itembfnl{\DWMACROstartfileTARG{}}
 A \DWMACROstartfileNAME{} entry has two operands. The
 first operand encodes the line number of the source line on
-which the \texttt{\#include} macro directive occurs.
-\bbeb
+which the \texttt{\#include} macro directive occurs. 
 The second operand encodes a source file name index. 
 
 The source file name index is the file number in the 
index e11d210..0796d71 100644 (file)
@@ -2045,11 +2045,8 @@ a trampoline will result in stepping into or setting the
 breakpoint in the target subroutine instead. This helps to
 hide the compiler generated subprogram from the user. }
 
-\bb
 \section{Call Site Entries and Parameters}
-\eb
 \label{chap:callsiteentriesandparameters}
-\bb
 \textit{
 A call site entry describes a call from one subprogram to another in the
 source program. It provides information about the actual parameters of
@@ -2072,29 +2069,25 @@ 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."}
-\eb
-
-\bbpareb
 
 A source call can be compiled into different types of machine code:
 \begin{itemize}
 \item
 A \textit{normal call} uses a call-like instruction which transfers 
 control to the start of some subprogram and preserves the call site 
-\bb
 location for use by the callee.
-\eb  
+
 \item
 A \textit{tail call} uses a jump-like instruction which
 transfers control to the start of some subprogram, but 
-\bb
 there is no call site location address to preserve
 (and thus none is available using the unwind information). 
-\eb 
+
 \item
 A \textit{tail recursion call} is a call
 to the current subroutine which is compiled as a jump 
 to the current subroutine.
+
 \needlines{4}
 \item
 An \textit{inline (or inlined) call} is a call to an inlined subprogram,
@@ -2119,11 +2112,8 @@ instructions are given a location in the caller.
 \DWTAGcallsite{} entries describe normal and tail calls but not tail recursion calls,
 while \DWTAGinlinedsubroutine{} entries describe inlined calls 
 (see Section \refersec{chap:inlinedsubroutines}).
-\bb
 Call site entries cannot describe tail recursion or optimized out calls.
-\eb
 
-\bb
 \subsection{Call Site Entries}
 \label{chap:callsiteentries}
 A call site is represented by a debugging information entry with the tag
@@ -2137,7 +2127,6 @@ call is present in the source program.
 otherwise be present in the debugging information of a subroutine
 need not be introduced solely to represent the immediately containing scope
 of a call.}
-\eb
 
 The call site entry may have a
 \DWATcallreturnpcDEFN{}\addtoindexx{call site return pc attribute}
@@ -2154,12 +2143,10 @@ be an address after the delay slot of the call.}
 
 The call site entry may have a 
 \DWATcallpcDEFN{}\addtoindexx{call pc attribute}
-\livetargi{chap:DWATcallpcofcallsite}{attribute}{call pc attribute} which is the
-address of the 
-\bb
+\livetargi{chap:DWATcallpcofcallsite}{attribute}{call pc attribute} 
+which is the address of the 
 call-like instruction for a normal call or the jump-like 
 instruction for a tail call.
-\eb 
 
 If the call site entry corresponds to a tail call, it has the 
 \DWATcalltailcallDEFN{}\addtoindexx{call tail call attribute}
@@ -2217,33 +2204,24 @@ interpreted in the same way as the declaration file, declaration
 line, and declaration column attributes, respectively 
 (see Section \refersec{chap:declarationcoordinates}).
 
-\textit{The call file, call line and call column coordinates do not describe the
-coordinates of the subroutine declaration that was called, rather they describe
-the coordinates of the call.}
+\textit{The call file, call line and call column coordinates do 
+not describe the coordinates of the subroutine declaration that 
+was called, rather they describe the coordinates of the call.}
 
 \needlines{5}
-\bb
 \subsection{Call Site Parameters}
-\eb
 \label{chap:callsiteparameters}
 The call site entry may own 
 \DWTAGcallsiteparameterTARG{}\index{call site parameter entry} 
-debugging information entries representing the parameters passed to the call.
-\bb
-Call site parameter entries occur in the same order as the corresponding
-parameters in the source.
-\eb
+debugging information entries representing the parameters passed 
+to the call.
+Call site parameter entries occur in the same order as the 
+corresponding parameters in the source.
 Each such entry has a \DWATlocation{} attribute which is a location 
-\bb
-description.
-\eb
-This location 
-\bb
-description 
-\eb
+description. This location description 
 describes where the parameter is passed
-(usually either some register, or a memory location expressible as the
-contents of the stack register plus some offset).
+(usually either some register, or a memory location expressible as 
+the contents of the stack register plus some offset).
 
 \needlines{4}
 Each \DWTAGcallsiteparameter{} entry may have a 
@@ -2268,18 +2246,10 @@ use the values at all.}
 For parameters passed by reference, where the code passes a pointer to
 a location which contains the parameter, or for reference type parameters,
 the \DWTAGcallsiteparameter{} entry may also have a
-\bb
 \DWATcalldatalocationDEFN{}\addtoindexx{call data location attribute}
-\eb
 \livetargi{chap:DWATcalldatalocationofcallparameter}{attribute}{call data location attribute}
-whose value is a location 
-\bb
-description 
-\eb
-and a
-\bb
+whose value is a location description and a
 \DWATcalldatavalueDEFN{}\addtoindexx{call data value attribute}
-\eb
 \livetargi{chap:DWATcalldatavalueofcallparameter}{attribute}{call data value attribute}
 whose value is a DWARF expression.  The \DWATcalldatalocationNAME{} attribute
 \addtoindexx{call data location attribute} 
index 9f6c469..9dd1217 100644 (file)
@@ -70,9 +70,7 @@ format would be represented by a change in the
 \dotdebugsup        & - & - & - & 5 \\
 \addtoindexi{\texttt{.debug\_types}}{\texttt{.debug\_types} (Version 4)}
                     & - & - & 4 & - \\
-\bb
 \hspace{3.5cm}\textit{(split object sections)}
-\eb
 \\
 \dotdebugabbrevdwo  & - & - & - & * \\
 \dotdebuginfodwo    & - & - & - & 5 \\
@@ -81,10 +79,8 @@ format would be represented by a change in the
 \dotdebugmacrodwo   & - & - & - & 5 \\
 \dotdebugstrdwo     & - & - & - & * \\
 \dotdebugstroffsetsdwo 
-                    & - & - & - & 5 \\
-\bb                    
+                    & - & - & - & 5 \\             
 \hspace{3.5cm}\textit{(package file sections)}
-\eb
 \\
 \dotdebugcuindex{}  & - & - & - & 5 \\
 \dotdebugtuindex{}  & - & - & - & 5 \\
index 4551671..25bddd9 100644 (file)
@@ -46,24 +46,20 @@ can be written to a separate DWARF object (.dwo{})
 \needlines{4}
 The optional set of debugging sections includes the following:
 \begin{itemize}
-\bb
 \item
 \dotdebugabbrevdwo{} - Contains the abbreviations table(s) used by
 the \dotdebuginfodwo{} section.
-\eb
 \item
 \dotdebuginfodwo{} - Contains the \DWTAGcompileunit{} and
 \DWTAGtypeunit{} DIEs and
 their descendants. This is the bulk of the debugging
 information for the compilation unit that is normally found
 in the \dotdebuginfo{} section.
-\bbeb
 \item
 \dotdebuglocdwo{} - Contains the location lists referenced by
 the debugging information entries in the \dotdebuginfodwo{}
 section. This contains the location lists normally found in 
 the \dotdebugloc{} section, with a 
-\bbeb 
 modified format to eliminate the need for relocations.
 \item
 \dotdebugstrdwo{} - Contains the string table for all indirect
@@ -94,17 +90,12 @@ corresponding to \DWFORMlinestrp{} in an executable file (for example,
 in the skeleton compilation unit) instead use \DWFORMstrx. This allows
 directory and file name strings to be merged with general
 strings and across compilations in package files 
-\bb
-(where they
-\eb
-are not subject to potential stripping).
+(where they are not subject to potential stripping).
 
 In a \texttt{.dwo} file, referring to a string using \DWFORMstrp{}
 is valid, but such use 
-\bb
 results in a file that cannot be incorporated into a package file
 (which involves string merging).
-\eb
 
 In order for the consumer to locate and process the debug
 information, the compiler must produce a small amount of debug
@@ -123,13 +114,10 @@ output binary include the following:
 \item
 \dotdebugabbrev{} - Contains the abbreviation codes used by the
 skeleton \dotdebuginfo{} section.
-\bb
 \item
 \dotdebugaddr{} - Contains references to loadable sections,
 indexed by attributes of form \DWFORMaddrx{} or location
-\bb
 expression 
-\eb
 \DWOPaddrx{} opcodes.
 \item
 \dotdebugaranges{} - Contains the accelerated range lookup table
@@ -147,15 +135,12 @@ be replaced by a new opcode that referenced an entry in the
 \dotdebugaddr{} section. Furthermore, leaving this section in the
 .o file allows many debug info consumers to remain unaware of
 .dwo files.)
-\bb
 \item
 \dotdebuglinestr{} - Contains strings for file names used in
 combination with the \dotdebugline{} section.
-\eb
 \item
 \dotdebugnames{} - Contains the names for use in
 building an index section. 
-\bbeb
 The section header refers to a
 compilation unit offset, which is the offset of the
 skeleton compilation unit in the \dotdebuginfo{} section.
@@ -167,15 +152,11 @@ skeleton compilation unit in the \dotdebuginfo{} section.
 \item
 \dotdebugstroffsets{} - Contains the string offsets table for
 the strings in the \dotdebugstr{} section (if form \DWFORMstrx{} is used).
-\eb
 \end{itemize}
 
 \needlines{6}
 The skeleton \DWTAGcompileunit{} DIE 
-\bb
-may have 
-\eb
-the following attributes:
+may have the following attributes:
 \autocols[0pt]{c}{3}{l}{
 \DWATaddrbase{},
 \DWATcompdir{},
@@ -189,8 +170,6 @@ the following attributes:
 \DWATstroffsetsbase{}
 }
 
-\bbpareb
-
 All other attributes of the compilation unit DIE are moved to
 the full DIE in the \dotdebuginfodwo{} section.
 The \DWATdwoid{} attribute is present
@@ -200,9 +179,7 @@ can verify a match.
 \needlines{4}
 
 Relocations are neither necessary nor useful in 
-\bb
 \texttt{.dwo} files, because the \texttt{.dwo}  
-\eb
 files contain only debugging information that does not need to be
 processed by a linker. Relocations are rendered unnecessary via
 four strategies:
@@ -214,9 +191,7 @@ compilation unit).
 
 \item Some values do not need a relocation because they refer from
 one \dotdwo{} section to another \dotdwo{} section
-\bb
 in the same compilation unit. 
-\eb
 
 \item Some values that need a relocation to refer to a
 relocatable program address use the \DWFORMaddrx{} form,
@@ -233,12 +208,9 @@ skeleton compilation unit in the \texttt{.o} file).
 
 Table \refersec{tab:unitattributesbyunitkind} summarizes which
 attributes are defined for use in the various 
-\bb
 kinds of compilation units (see Section \refersec{chap:unitentries}). 
 It compares and contrasts both conventional and split object-related
 kinds.
-\eb
-
 
 \begin{table}[ht]
 \caption{Unit attributes by unit kind}
@@ -246,7 +218,7 @@ kinds.
 \begin{tabular}{P{5.5cm}|cc|ccc}
 \hline
                         & \multicolumn{5}{c}{\bfseries Unit Kind} \\
-\bbeb                   & \multicolumn{2}{c}{\bfseries Conventional} 
+                        & \multicolumn{2}{c}{\bfseries Conventional} 
                                               & \multicolumn{3}{c}{\bfseries Skeleton and Split} \\
 \bfseries Attribute     & Full \&    &  Type  &  Skeleton & Split Full & Split Type \\
                         & Partial    &        &           &            &            \\
@@ -263,13 +235,13 @@ kinds.
 \hline
 \DWATentrypc            & \chkmk  &        &           & \chkmk &         \\
 \hline
-\bbeb\DWAThighpc             & \chkmk  &        &  \chkmk   &        &         \\
+\DWAThighpc             & \chkmk  &        &  \chkmk   &        &         \\
 \hline
 \DWATidentifiercase     & \chkmk  &        &           & \chkmk &         \\
 \hline
 \DWATlanguage           & \chkmk  & \chkmk &           & \chkmk & \chkmk  \\
 \hline
-\bbeb\DWATlowpc              & \chkmk  &        &  \chkmk   &        &         \\
+\DWATlowpc              & \chkmk  &        &  \chkmk   &        &         \\
 \hline
 \DWATmacros             & \chkmk  &        &           & \chkmk &         \\
 \hline
@@ -279,7 +251,7 @@ kinds.
 \hline
 \DWATproducer           & \chkmk  &        &           & \chkmk &         \\
 \hline
-\bbeb\DWATranges             & \chkmk  &        &  \chkmk   &        &         \\
+\DWATranges             & \chkmk  &        &  \chkmk   &        &         \\
 \hline
 \DWATrangesbase         & \chkmk  &        &  \chkmk   &        &         \\
 \hline
@@ -287,13 +259,11 @@ kinds.
 \hline
 \DWATstroffsetsbase     & \chkmk  & \chkmk &  \chkmk   &        &         \\
 \hline
-\bbeb\DWATuseUTFeight        & \chkmk  & \chkmk &  \chkmk   & \chkmk & \chkmk  \\
+\DWATuseUTFeight        & \chkmk  & \chkmk &  \chkmk   & \chkmk & \chkmk  \\
 \hline
 \end{tabular}
 \end{table}
 
-
-
 \needlines{8}
 The split dwarf object file design depends on having an index of 
 debugging information available to the consumer. For name lookups, 
@@ -495,33 +465,24 @@ omitted, and instead replaced by the pair \DWATlowpc{} and
 The \DWATstmtlist{} attribute contains the relocatable offset of
 this file's contribution to the \dotdebugline{} table.
 
-\bb
 There is both a \DWATranges{} attribute as well as a \DWATlowpc{} 
-attribute which
-\eb
+attribute which 
 provides a default base address for the range list entries in the
 \dotdebugranges{} section. 
-\bbeb
 
 The \dotdebugranges{} section contains the range list referenced by
 the \DWATranges{} attribute in the skeleton compilation unit DIE,
 plus any range lists referenced by \DWATranges{} attributes in the
-split DWARF object. In 
-\bb
-this example, \texttt{demo1.o} contains range
-\eb
+split DWARF object. In this example, \texttt{demo1.o} contains range
 list entries for the function \texttt{Box::contains}, as well as for
 out-of-line copies of the inline functions \texttt{Point::x} and 
 \texttt{Point::y}.
 
 The \dotdebugline{} section contains the full line number table for
-the compiled code in the object file. 
-\bb
-As shown in
+the compiled code in the object file. As shown in
 Figure \refersec{fig:splitobjectexamplesourcefragment1}, the line
 number program header lists the two file names, \texttt{demo.h} and
 \texttt{demo1.cc}, and contains line number programs for
-\eb
 \texttt{Box::contains}, \texttt{Point::x}, and \texttt{Point::y}.
 
 The \dotdebugstr{} section contains the strings referenced indirectly
@@ -576,7 +537,6 @@ The \splitDWARFobjectfile{s} each contain the following sections:
 The \dotdebugabbrevdwo{} section contains the abbreviation
 declarations for the debugging information entries in the
 \dotdebuginfodwo{} section. 
-\bbeb
 
 The \dotdebuginfodwo{} section containing the compilation unit
 contains the full debugging information for the compile unit, and
@@ -589,27 +549,22 @@ object file, with the following exceptions:
 compilation unit.
 
 \item References to strings in the string table use the 
-\bbeb
 form code \DWFORMstrx, referring to slots in the
 \dotdebugstroffsetsdwo{} section.
 
-\bbpareb
-
 \item References to range lists in the \dotdebugranges{} section are
 all relative to the base offset given by \DWATrangesbase{}
 in the skeleton compilation unit.
 
 \needlines{4}
-\item References to relocatable addresses in the object file use the 
-\bbeb 
-form code \DWFORMaddrx, referring to slots in the
+\item References to relocatable addresses in the object file 
+use the form code \DWFORMaddrx, referring to slots in the
 \dotdebugaddr{} table, relative to the base offset given by
 \DWATaddrbase{} in the skeleton compilation unit.
 \end{itemize}
 
 \vspace*{1mm}
 Figure \referfol{fig:splitobjectexampledemoonedwodwarfexcerpts} presents
-\bbeb
 excerpts from the \dotdebuginfodwo{} section for \texttt{demo1.dwo}.
 
 \begin{figure}[ht]
@@ -735,7 +690,6 @@ within the type unit.
 
 The \dotdebugstroffsetsdwo{} section contains an entry for each
 unique string in the string table. 
-\bbeb
 Each entry in the table is the offset of the string, which is
 contained in the \dotdebugstrdwo{} section. 
 
@@ -755,10 +709,8 @@ within the merged string table (\dotdebugstrdwo{}).
 The tool that builds the DWARF package file must understand 
 the structure of the \dotdebugstroffsetsdwo{} section in 
 order to apply the necessary adjustments. 
-\bb
 Section \refersec{app:dwarfpackagefileexample} presents
 an example of a DWARF package file.
-\eb
 
 \needlines{4}
 The \dotdebuglocdwo{} section contains the location lists referenced
@@ -840,14 +792,8 @@ Figure~\ref{fig:splitobjectexampledemotwodwodwarfdebuginfodwoexcerpts}: Split ob
 In \texttt{demo2.dwo} as shown in 
 Figure \refersec{fig:splitobjectexampledemotwodwodwarfdebuginfodwoexcerpts}, 
 the debugging information for \texttt{Line::clip} 
-\bb
-starting at \texttt{2\$}
-\eb
-describes a local 
-variable \texttt{slope} 
-\bb
-at \texttt{7\$}
-\eb
+starting at \texttt{2\$} describes a local 
+variable \texttt{slope} at \texttt{7\$}
 whose location varies based on the PC.
 Figure \refersec{fig:splitobjectexampledemotwodwodwarfdebuglocdwoexcerpts} 
 presents some excerpts from the \dotdebuginfodwo{} section for 
@@ -859,7 +805,6 @@ In Figure \refersec{fig:splitobjectexampledemotwodwodwarfdebuginfodwoexcerpts},
 the \DWTAGformalparameter{} entries at \texttt{4\$} and \texttt{5\$} refer to the
 location lists at offset \texttt{0x0} and \texttt{0x2a}, respectively, and the
 \DWTAGvariable{} entry for \texttt{slope} 
-\bbeb
 refers to the location list at offset \texttt{0x49}. 
 Figure \refersec{fig:splitobjectexampledemotwodwodwarfdebuglocdwoexcerpts}
 shows a representation of the
@@ -882,8 +827,8 @@ offset & (DW\_LLE\_*)         & start & length & length & expression \\
 
 0x00 & \XXLLEsl &  [9] & 0x002f & 0x0001 & \DWOPregfive~(rdi) \\
 0x09 & \XXLLEsl & [11] & 0x01b9 & 0x0001 & \DWOPregthree~(rbx) \\
-\bbeb 0x12 & \XXLLEsl & [29] & 0x0003 & 0x0003 & \DWOPbregtwelve~(r12): -8;\\
-\bbeb      &          &      &        &        & \DWOPstackvalue \\
+0x12 & \XXLLEsl & [29] & 0x0003 & 0x0003 & \DWOPbregtwelve~(r12): -8;\\
+     &          &      &        &        & \DWOPstackvalue \\
 0x1d & \XXLLEsl & [31] & 0x0001 & 0x0003 & \DWOPentryvalue: \\
      &          &      &        &        & (\DWOPregfive~(rdi)); \\
      &          &      &        &        & \DWOPstackvalue \\
@@ -914,22 +859,17 @@ offset defined by the compilations unit's \DWATaddrbase{}
 attribute. The \dotdebugaddr{} slots referenced by these entries give
 the relocated address of a label within the function where the
 address range begins. 
-\bb
 The following length field gives the length of the
 address range. The location, consisting of its own length and
 a DWARF expression, is last.
-\eb 
 
 \clearpage
 \section{DWARF Package File Example}
 \label{app:dwarfpackagefileexample}
 \addtoindexx{DWARF duplicate elimination!examples}
 
-A 
-\bb
-\addtoindex{DWARF package file} 
-(see Section \refersec{datarep:dwarfpackagefiles})
-\eb
+A \addtoindex{DWARF package file} 
+(see Section \refersec{datarep:dwarfpackagefiles}) 
 is a collection of split DWARF object files.
 In general, it will be much smaller than the sum of the split
 DWARF object files, because the packaging process removes duplicate
@@ -956,9 +896,7 @@ sections specially. Rather than
 combining them by simple concatenation, it instead builds a new
 string table consisting of the unique strings from each input
 string table. Because all references to these strings use
-\bb
 form \DWFORMstrx{},
-\eb
 the packaging utility only needs to adjust the
 string offsets in each \dotdebugstroffsetsdwo{} contribution after
 building the new \dotdebugstrdwo{} section.
@@ -986,7 +924,7 @@ with contributions from each input file as shown.
 \begin{center}
 \begin{tabular}{P{4.7cm}|P{8cm}}
 \hline
-\bfseries \bbeb Section & \bfseries Source of section contributions \\
+\bfseries Section & \bfseries Source of section contributions \\
 \hline
   \dotdebugabbrevdwo{}
 &    \dotdebugabbrevdwo{} from \texttt{demo1.dwo} \newline
@@ -1012,13 +950,13 @@ with contributions from each input file as shown.
      \dotdebugstroffsetsdwo{} from \texttt{demo2.dwo}, \hspace*{6mm}adjusted \\
 \hline
   \dotdebugstrdwo{}
-&    \bbeb merged string table generated by package utility \\
+&    merged string table generated by package utility \\
 \hline
   \dotdebugcuindex
-&    \bbeb CU index generated by package utility \\
+&    CU index generated by package utility \\
 \hline
   \dotdebugtuindex
-&    \bbeb TU index generated by package utility \\
+&    TU index generated by package utility \\
 \hline
 \end{tabular}
 \end{center}
@@ -1028,51 +966,27 @@ with contributions from each input file as shown.
 
 \needlines{4}
 The \dotdebugabbrevdwo{}, \dotdebuglocdwo{} and \dotdebuglinedwo{}
-sections 
-\bb
-are
-\eb
-copied over from the two \texttt{.dwo} files as
+sections are copied over from the two \texttt{.dwo} files as
 individual contributions to the corresponding sections in the
 \texttt{.dwp} file. 
-\bb
-The
-\eb
-offset of each contribution within 
+The offset of each contribution within 
 the combined section and the size of each contribution is recorded
 as part of the CU and TU index sections.
 
-The \dotdebuginfodwo{} sections corresponding to each compilation unit 
-\bb
-are
-\eb
-copied as individual contributions to the combined
+The \dotdebuginfodwo{} sections corresponding to each compilation 
+unit are copied as individual contributions to the combined
 \dotdebuginfodwo{} section, and one copy of each type unit 
-\bb
-is also
-\eb
-copied. The type units for class \texttt{Box} and class 
+is also copied. The type units for class \texttt{Box} and class 
 \texttt{Point}, for example, are contained in both \texttt{demo1.dwo} 
 and \texttt{demo2.dwo}, but only one instance of each is copied into 
 the package file.
 
-The \dotdebugstrdwo{} sections from each file 
-\bb
-are
-\eb
-merged to
+The \dotdebugstrdwo{} sections from each file are merged to
 form a new string table with no duplicates, requiring the
 adjustment of all references to those strings. The
 \dotdebugstroffsetsdwo{} sections from the \texttt{.dwo} files 
-\bb
-are
-\eb
-copied as individual contributions, but the string table offset
-in each slot of those contributions 
-\bb
-is
-\eb
-adjusted to point to
+are copied as individual contributions, but the string table offset
+in each slot of those contributions is adjusted to point to
 the correct offset in the merged string table.
 
 \needlines{4}
index f4116e6..7a4cbb3 100644 (file)
@@ -4,7 +4,6 @@ This section presents the debugging information entries
 that describe program types: base types, modified types and
 user-defined types.
 
-\bbpareb
 
 \section{Base Type Entries}
 \label{chap:basetypeentries}
@@ -42,7 +41,6 @@ is the default for the target architecture.
 
 \needlines{4}
 A base type entry has a
-\bbeb
 \addtoindexx{byte size attribute}
 \DWATbytesize{}\hypertarget{chap:DWATbytesizedataobjectordatatypesize}{}
 attribute or a
@@ -76,7 +74,6 @@ values of the given type. The data bit offset attribute is the
 offset in bits from the beginning of the containing storage to
 the beginning of the value. Bits that are part of the offset
 are padding. 
-\bbeb
 If this attribute is omitted a default data bit offset
 of zero is assumed.
 
@@ -353,7 +350,6 @@ has a \DWATname{} attribute
 whose value is
 a null\dash terminated
 string containing the name.
-\bbeb
 
 \textit{The interpretation of this debugging information entry is
 intentionally left flexible to allow it to be interpreted
@@ -405,7 +401,6 @@ a \DWATname{} attribute
 \addtoindexx{name attribute}
 whose value is a null\dash terminated
 string containing the modified type name. 
-\bbeb
 
 Each of the type modifier entries has 
 \addtoindexx{type attribute}
@@ -547,7 +542,6 @@ The typedef entry has a \DWATname{} attribute
 \addtoindexx{name attribute}
 whose value is a null\dash terminated string containing
 the name of the typedef.
-\bbeb
 
 The typedef entry may also contain 
 \addtoindexx{type attribute}
@@ -588,7 +582,6 @@ array type entry has a \DWATname{} attribute
 \addtoindexx{name attribute}
 whose value is a
 null-terminated string containing the array type name.
-\bbeb
 
 The\hypertarget{chap:DWATorderingarrayrowcolumnordering}{}
 array type entry describing a multidimensional array may
@@ -612,8 +605,6 @@ of the enclosing compilation unit entry) is assumed.
 \DWORDrowmajorTARG{} \\
 \end{simplenametable}
 
-\bbpareb
-
 An array type entry has 
 \addtoindexx{type attribute}
 a \DWATtype{} attribute
@@ -707,7 +698,6 @@ If a name has been given to the
 coarray type in the source, then the corresponding coarray type 
 entry has a \DWATname{} attribute whose value is a null-terminated 
 string containing the array type name.
-\bbeb
 
 A coarray entry has one or more \DWTAGsubrangetype{} child entries,
 one for each codimension. It also has a \DWATtype{} attribute 
@@ -784,7 +774,6 @@ structure type, union type, or class type entry has a
 \addtoindexx{name attribute}
 whose value is a null\dash terminated string
 containing the type name.
-\bbeb
 
 The members of a structure, union, or class are represented
 by debugging information entries that are owned by the
@@ -938,9 +927,8 @@ tag \DWTAGinterfacetypeTARG.
 An interface type entry has 
 a \DWATname{} attribute,
 \addtoindexx{name attribute}
-whose
-value is a null\dash terminated string containing the type name.
-\bbeb
+whose value is a null\dash terminated string containing the 
+type name.
 
 The members of an interface are represented by debugging
 information entries that are owned by the interface type
@@ -1048,7 +1036,6 @@ Each such entry is a child of the class or structure type entry.
 An access declaration entry has a \DWATname{} attribute, 
 whose value is a null-terminated string representing the name 
 used in the declaration,
-\bbeb
 including any class or structure qualifiers.
 
 An\hypertarget{chap:DWATaccessdeclaration}{} 
@@ -1088,7 +1075,6 @@ a \DWATname{} attribute
 \addtoindexx{name attribute}
 whose value is a null\dash terminated
 string containing the member name.
-\bbeb
 If the member entry describes an 
 \addtoindex{anonymous union},
 the name attribute is omitted or the value of the attribute
@@ -1125,8 +1111,6 @@ address. When the storage for an entity includes all of
 the bits in the beginning byte, the beginning bit offset is
 defined to be zero.
 
-\bbpareb
-
 The\hypertarget{chap:DWATdatabitoffsetdatamemberbitlocation}{}
 member\hypertarget{chap:DWATdatamemberlocationdatamemberlocation}{} 
 entry \addtoindexx{member entry (data)}
@@ -1526,7 +1510,6 @@ has been given to the condition, the condition entry has a
 \addtoindexx{name attribute}
 whose value is a null\dash terminated string
 giving the condition name.
-\bbeb
 
 \needlines{4}
 The condition entry's parent entry describes the conditional
@@ -1580,7 +1563,6 @@ a \DWATname{} attribute
 \addtoindexx{name attribute}
 whose value is a null\dash terminated
 string containing the enumeration type name.
-\bbeb
 
 The \addtoindex{enumeration type entry}
 may have 
@@ -1588,17 +1570,13 @@ may have
 a \DWATtype{} attribute
 which refers to the underlying data type used to implement
 the enumeration. The entry also may have a
-\bb
 \DWATbytesize{} attribute or 
 \DWATbitsize{}
 attribute, whose value 
 (see Section \refersec{chap:byteandbitsizes}) 
 is the amount of storage 
-\eb
-required to hold an instance of the enumeration. If no \DWATbytesize{} 
-\bb
-or \DWATbitsize{}
-\eb
+required to hold an instance of the enumeration. If no 
+\DWATbytesize{} or \DWATbitsize{}
 attribute is present, the size for holding an instance of the 
 enumeration is given by the size of the underlying data type.
 
@@ -1647,7 +1625,6 @@ Each \addtoindex{enumerator entry} has a \DWATname{} attribute, whose
 value is a null-terminated string containing the name of 
 the\hypertarget{chap:DWATconstvalueenumerationliteralvalue}{}
 enumeration literal.
-\bbeb
 Each enumerator entry also has a 
 \DWATconstvalueDEFN{} attribute,
 \addtoindexx{constant value attribute}
@@ -1698,7 +1675,6 @@ a \DWATname{} attribute
 \addtoindexx{name attribute}
 whose value is a null\dash terminated string containing
 the subroutine type name.
-\bbeb
 
 If the subroutine type describes a function that returns
 a value, then the subroutine type entry has a
@@ -1783,7 +1759,6 @@ string type entry has a
 \DWATname{} attribute
 \addtoindexx{name attribute}
 whose value is a null-terminated string containing the string type name.
-\bbeb
 
 A string type entry may have a \DWATtypeDEFN{} 
 \livetargi{chap:DWAATtypeofstringtype}{attribute}{type attribute!of string type entry}
@@ -1869,7 +1844,6 @@ a \DWATname{} attribute
 \addtoindexx{name attribute}
 whose value is a null\dash terminated string containing the
 set type name.
-\bbeb
 
 The set type entry has a
 \addtoindexx{type attribute}
@@ -1903,7 +1877,6 @@ subrange type entry has a
 \DWATname{} attribute\addtoindexx{name attribute}
 whose value is a null-terminated
 string containing the subrange type name.
-\bbeb
 
 The tag \DWTAGgenericsubrange{}
 is used to describe arrays with a dynamic rank. See Section
@@ -2019,7 +1992,6 @@ pointer to member entry has a
 \addtoindexx{name attribute}
 whose value is a
 null\dash terminated string containing the type name.
-\bbeb
 
 The \addtoindex{pointer to member} entry 
 has 
@@ -2100,7 +2072,6 @@ the file type entry has a \DWATname{} attribute,
 \addtoindexx{name attribute}
 whose value
 is a null\dash terminated string containing the type name.
-\bbeb 
 
 The file type entry has 
 \addtoindexx{type attribute}
@@ -2133,7 +2104,6 @@ with the tag \DWTAGdynamictypeTARG. If a name has been given to the
 dynamic type, then the dynamic type has a \DWATname{} attribute 
 whose value is a null-terminated string containing the dynamic
 type name.
-\bbeb
        
 A dynamic type entry has a \DWATtype{} attribute whose value is a
 reference to the type of the entities that are dynamically allocated.
@@ -2164,7 +2134,6 @@ The template alias entry has a
 \addtoindexx{name attribute}
 whose value is a null\dash terminated string
 containing the name of the template alias.
-\bbeb 
 The template alias entry has child entries describing the template
 actual parameters (see Section \refersec{chap:templateparameters}).
 
@@ -2237,7 +2206,6 @@ an object of the type is currently associated or not.
 
 The value of these attributes is determined as described in
 Section \refersec{chap:staticanddynamicvaluesofattributes}.
-\bbeb
 A non-zero value is interpreted as allocated or associated,
 and zero is interpreted as not allocated or not associated.