Working checkpoint for editoial changes resulting from the
authorRon Brender <ron.brender@gmail.com>
Fri, 28 Aug 2015 14:54:55 +0000 (10:54 -0400)
committerRon Brender <ron.brender@gmail.com>
Fri, 28 Aug 2015 14:54:55 +0000 (10:54 -0400)
Aug 25-26, 2015 review meetings. Try out the line numbering
feature (package lineno).

Signed-off-by: Ron Brender <ron.brender@gmail.com>
13 files changed:
dwarf5/latexdoc/changesummary.tex
dwarf5/latexdoc/compression.tex
dwarf5/latexdoc/dataobject.tex
dwarf5/latexdoc/datarepresentation.tex
dwarf5/latexdoc/dwarf5.tex
dwarf5/latexdoc/examples.tex
dwarf5/latexdoc/foreword.tex
dwarf5/latexdoc/generaldescription.tex
dwarf5/latexdoc/introduction.tex
dwarf5/latexdoc/otherdebugginginformation.tex
dwarf5/latexdoc/programscope.tex
dwarf5/latexdoc/splitobjects.tex
dwarf5/latexdoc/typeentries.tex

index 6019601..a72c94f 100644 (file)
@@ -15,7 +15,8 @@ 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
-9/17/2015       & Editorial work XI \\
+8/26-27/2015    & Editorial work from group review \\
+8/17/2015       & Editorial work XI \\
 7/28-8/11/2015  & 150623.1 (MD5 digest), new F.3 (.dwp files), remove trial Selected Glossary, \\
                 & replace Fig 6.1 (again), more editorial work X \\
 6/30-7/14/2015  & Revise 3.1 Compilation Units, replace Figure 6.1 (Name index), \\
index 570d5aa..af32f0b 100644 (file)
@@ -299,7 +299,7 @@ symbol table, whether the current compilation references all
 those points or not.
 
 \textit{The completeness of the set of names generated is a
-quality\dash of\dash implementation issue.}
+quality-of-implementation issue.}
 
 It is up to the producer to ensure that if 
 \textless die\dash numbers\textgreater\ 
index e0dd36b..8d5f141 100644 (file)
@@ -265,7 +265,7 @@ Name&Meaning\\ \hline
 \DWENDdefaultTARG{} &  Default endian encoding
   (equivalent to the \mbox{absence} of a 
   \DWATendianity{} attribute) \\
-\DWENDbigTARG{} & Big\dash endian encoding \\
+\DWENDbigTARG{} & Big-endian encoding \\
 \DWENDlittleTARG& Little-endian encoding \\
 \hline
 \end{tabular}
index bf02b2b..8c1c8d4 100644 (file)
@@ -405,10 +405,7 @@ section.
 
 The DWARF package file also contains two index sections that
 provide a fast way to locate debug information by compilation
-\bb
-unit ID 
-\eb
-(\DWATdwoid) for compilation units, or by type
+unit ID (\DWATdwoid) for compilation units, or by type
 signature for type units:
 \begin{alltt}
     \dotdebugcuindex
@@ -417,11 +414,7 @@ signature for type units:
 
 \subsubsection{The Compilation Unit (CU) Index Section}
 The \dotdebugcuindex{} section is a hashed lookup table that maps a
-compilation unit
-\bb
-ID 
-\eb
-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.
 
@@ -514,28 +507,18 @@ 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.
 
-\bb
-Given an 8-byte compilation unit ID
-\eb
-or 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. ]
-\bb
 \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
-\eb 
       $MASK(k)$ is a mask with the low-order $k$ bits all set to 1.
-\bb
 \item Calculate a secondary hash $H' = (((REP(X)>>32)\ \&\ MASK(k))\ |\ 1)$.
-\eb
-
 \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\ S$. Repeat at Step 4.
 \end{enumerate}
 
@@ -2095,8 +2078,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}
index 110b759..3c66e3e 100644 (file)
@@ -3,25 +3,18 @@
 % 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}{August 17, 2015}
+\newcommand{\docdate}{August 27, 2015}
 %
 \usepackage{ifthen}
-\newcommand{\ifthen}[2]{\ifthenelse{#1}{#2}{}}
-\newboolean{isdraft}\setboolean{isdraft}{true}
+    \newcommand{\ifthen}[2]{\ifthenelse{#1}{#2}{}}
+    \newboolean{isdraft}\setboolean{isdraft}{true}
+    \newboolean{uselinenos}\setboolean{uselinenos}{true}
 \newcommand{\draftmark}{\ifthenelse{\boolean{isdraft}}{*** DRAFT ***}{}}
 %
 \usepackage[T1]{fontenc}
 \usepackage{palatino}
 \usepackage{cmtt}
-\renewcommand{\ttdefault}{cmtt}        % Use Computer Modern Typewriter instead of Courier
-%\usepackage{ascii}
-%\renewcommand{\ttdefault}{ascii}
-%\renewcommand{\ttfamily}{\asciifamily}
-%\usepackage{microtype}
-%\DisableLigatures[f]{encoding=T1}
-%\renewcommand{\familydefault}{phv}  % font family helvetica
-%
-
+    \renewcommand{\ttdefault}{cmtt}    % Use Computer Modern Typewriter instead of Courier
 \usepackage{url}          % for color in letters. Links instead?
 \usepackage[usenames]{color}%for color in letters. Links instead?
 \usepackage{ellipsis}     % provides ... as \dots
@@ -50,33 +43,34 @@ breakatwhitespace=false,   % sets if automatic breaks should only happen at whit
 escapeinside={\%*}{*)}     % if you want to add a comment within your code
 }
 \usepackage{float}
-\restylefloat{figure}
+    \restylefloat{figure}
 \usepackage{amsmath}       % Provides \nobreakdash
 \usepackage{amssymb}       % maths
 \usepackage{graphicx}      % For pictures
 \usepackage{epstopdf}      % Autoconvert .eps to .pdf
-\epstopdfsetup{suffix=-generated} % Mark generaed PDF as such
+    \epstopdfsetup{suffix=-generated} % Mark generaed PDF as such
+\usepackage{lineno}        % line numbers
 \usepackage{longtable}     % For multipage tables
 \usepackage{hhline}        % Single column horizontal lines
 \usepackage{varioref}      % defines \vref
-% \textregistered is the trademark symbol
+%   \textregistered is the trademark symbol
 \usepackage[headheight=16pt,paper=letterpaper]{geometry}
-\setlength{\headheight}{15pt}  % avoids warning from latex
+    \setlength{\headheight}{15pt}  % avoids warning from latex
 \usepackage{needspace}     % For assuring space remaining on a page
 \usepackage{ifthen}        % For conditional processing
 \usepackage{changepage}    % For odd/even page checks
 \usepackage[usenames,dvipsnames]{xcolor}
 \usepackage{lscape}        % For landscape mode (Appendix B)
 \usepackage{tikz}         % graphics (Name Index (Fig 6.1), Appendix B)
-\usetikzlibrary{arrows}
-\usetikzlibrary{arrows.meta}
-\usetikzlibrary{backgrounds}
-\usetikzlibrary{calc}
-\usetikzlibrary{chains}
-\usetikzlibrary{decorations.pathreplacing}
-\usetikzlibrary{shapes.geometric}
-\usetikzlibrary{shapes.multipart}
-\usetikzlibrary{shapes.symbols}
+    \usetikzlibrary{arrows}
+    \usetikzlibrary{arrows.meta}
+    \usetikzlibrary{backgrounds}
+    \usetikzlibrary{calc}
+    \usetikzlibrary{chains}
+    \usetikzlibrary{decorations.pathreplacing}
+    \usetikzlibrary{shapes.geometric}
+    \usetikzlibrary{shapes.multipart}
+    \usetikzlibrary{shapes.symbols}
 \usepackage{changebar}     % For change bars in margin
 \usepackage{makeidx}       % For making an index
 % hyperref must be the last package listed.
@@ -171,7 +165,7 @@ escapeinside={\%*}{*)}     % if you want to add a comment within your code
 \newcommand{\needlines}[1]{\needspace{#1\baselineskip}}
 
 % Helper for item lists with bold subject markers
-\newcommand{\itembf}[1]{\item \textbf{#1}}
+\newcommand{\itembf}[1]{\needlines{4} \item \textbf{#1}}
 \newcommand{\itembfnl}[1]{\itembf{#1} \\}
 
 % And description lists with normal (not bold) text
@@ -181,7 +175,11 @@ escapeinside={\%*}{*)}     % if you want to add a comment within your code
 \newcommand{\emptypage}{
     \clearpage
     \vspace*{4in}
-    \begin{center} \textit{(empty page)} \end{center}
+    \begin{nolinenumbers}
+    \begin{center} 
+        \textit{(empty page)} 
+    \end{center}
+    \end{nolinenumbers}
     }
 
 % Define a new column type P that is just like p except
@@ -213,9 +211,12 @@ escapeinside={\%*}{*)}     % if you want to add a comment within your code
 % Complement of \isundefined
 \newcommand{\isdefined}[1]{\not{\isundefined{#1}}}
 
+\newcommand{\uselinenos}{\ifthen{\boolean{uselinenos}}{\linenumbers*}}
+
 % Preferred changebar asliases
 \newcommand{\bb}{\cbstart}      % Begin (change) bar
 \newcommand{\eb}{\cbend}        % End (change) bar
+\newcommand{\bbpareb}{\bb~\eb\vspace{-1.5\baselineskip}} % Mark deleted paragraph
 
 % Define commands for all of the DWARF names (DW\_*, .debug_*, a few others)
 %
@@ -335,25 +336,26 @@ escapeinside={\%*}{*)}     % if you want to add a comment within your code
 % Define the levels of sectionality that are numbered.
 \setcounter{secnumdepth}{5}
 
-\include{introduction}                  %\emptypage
-\include{generaldescription}            \emptypage
-\include{programscope}                  \emptypage
-\include{dataobject}                    %\emptypage
-\include{typeentries}                   %\emptypage
-\include{otherdebugginginformation}    \emptypage
-\include{datarepresentation}            %\emptypage
+\uselinenos\include{introduction}              %\emptypage
+\uselinenos\include{generaldescription}        %\emptypage
+\uselinenos\include{programscope}              \emptypage
+\uselinenos\include{dataobject}                %\emptypage
+\uselinenos\include{typeentries}               %\emptypage
+\uselinenos\include{otherdebugginginformation} \emptypage
+\uselinenos\include{datarepresentation}        %\emptypage
 
 %  The \appendix command toggles us into appendix chapters
 \appendix
 
-\include{attributesbytag}              %\emptypage
-\include{debugsectionrelationships}     \emptypage
-\include{encodingdecoding}              \emptypage
-\include{examples}                      %\emptypage
-\include{compression}                   \emptypage
-\include{splitobjects}                 \emptypage
-\include{sectionversionnumbers}         \emptypage
-\include{gnulicense}                    \emptypage
+\uselinenos\include{attributesbytag}          %\emptypage
+\uselinenos\include{debugsectionrelationships} \emptypage
+\uselinenos\include{encodingdecoding}          \emptypage
+\uselinenos\include{examples}                  %\emptypage
+\uselinenos\include{compression}               \emptypage
+\uselinenos\include{splitobjects}             \emptypage
+\uselinenos\include{sectionversionnumbers}     \emptypage
+\nolinenumbers
+\include{gnulicense}                           \emptypage
 
 % Maybe someday the selected glossary concept will be of interest...
 %\include{selectedglossary}             %\emptypage
index fc5e72b..0b16085 100644 (file)
@@ -1257,8 +1257,8 @@ is appropriate.
 \DWTAGpackedtype{} entries could be added to
 better represent the source, but these do not otherwise affect
 the example and are omitted for clarity. Note that this same
-representation applies to both typical big\dash \ and 
-little\dash endian
+representation applies to both typical big- and 
+little-endian
 architectures using the conventions described in 
 Section \refersec{chap:datamemberentries}.
 
@@ -1356,15 +1356,15 @@ conventions in examples. These conventions are for illustrative
 purposes and other conventions may apply on particular
 architectures.}
 \begin{itemize}
-\item \textit{For big\dash endian architectures, bit offsets are
-counted from high-order to low\dash order bits within a byte (or
+\item \textit{For big-endian architectures, bit offsets are
+counted from high-order to low-order bits within a byte (or
 larger storage unit); in this case, the bit offset identifies
-the high\dash order bit of the object.}
+the high-order bit of the object.}
 
 \item \textit{For little-endian architectures, bit offsets are
-counted from low\dash order to high\dash order bits within a byte (or
+counted from low-order to high-order bits within a byte (or
 larger storage unit); in this case, the bit offset identifies
-the low\dash order bit of the object.}
+the low-order bit of the object.}
 \end{itemize}
 
 \textit{In either case, the bit so identified is defined as the 
@@ -1445,9 +1445,9 @@ the right.
 
 \needlines{4}
 Note that data member bit offsets in this example are the
-same for both big\dash\ and little\dash endian architectures even
+same for both big- and little-endian architectures even
 though the fields are allocated in different directions
-(high\dash order to low-order versus low\dash order to high\dash order);
+(high-order to low-order versus low-order to high-order);
 the bit naming conventions for memory and/or registers of
 the target architecture may or may not make this seem natural.
 
index 6870ec4..56a77c5 100644 (file)
@@ -41,11 +41,10 @@ It is the intention of the DWARF Committee that migrating from
 an earlier version of the DWARF standard to the current version
 should be straightforward and easily accomplished. 
 Almost all constructs from
-\addtoindex{DWARF Version 2} onward 
-\addtoindexx{DWARF Version 3}
-\addtoindexx{DWARF Version 4}
-have been retained unchanged in DWARF Version 5, although a few
-\addtoindexx{DWARF Version 5}
+\bb
+\DWARFVersionII\addtoindexx{DWARF Version 3}\addtoindexx{DWARF Version 4}
+\eb
+onward have been retained unchanged in \DWARFVersionV, although a few
 have been compatibly superseded by improved constructs which are
 more compact and/or more expressive.
 
@@ -69,22 +68,27 @@ David Anderson, Associate Editor\\
 John Bishop             & Intel\\
 Ron Brender, Editor\\
 Andrew Cagney\\
-Soumitra Chatterjee     & HP \\
+\bb
+Soumitra Chatterjee     & Hewlett-Packard Enterprise\eb\\
 Eric Christopher        & Google\\
 Cary Coutant            & Google\\
 John DelSignore         & Rogue Wave\\
 Michael Eager, Chair    & Eager Consulting\\
-Jini Susan George       & HP \\
+\bb
+Jini Susan George       & Hewlett-Packard\eb\\
 Mathhew Gretton-Dan     & ARM\\
 Tommy Hoffner           & Altera\\
-Jakub Jelinek           & RedHat\\
+\bb
+Jakub Jelinek           & Red Hat\eb\\
 Andrew Johnson          & Linaro\\
-Jason Merrill           & RedHat\\
+\bb
+Jason Merrill           & Red Hat\eb\\
 Jason Molenda           & Apple\\
 Adrian Prantl           & Apple\\
 Hafiz Abid Qadeer       & Mentor Graphics\\
 Paul Robinson           & Sony\\
-Syamala Sarma           & HP\\
+\bb
+Syamala Sarma           & Hewlett-Packard\eb\\
 Keith Walker            & ARM\\
 Kendrick Wong           & IBM\\
 Brock Wyma              & Intel\\
@@ -112,9 +116,20 @@ traditional paper forms. Both online and paper forms include
 page numbers, a Table of Contents, a List of Figures,
 a List of Tables and an Index.
 
+\bb
+Text in normal font describes
+required aspects of the DWARF format.  Text in \textit{italics} is
+explanatory or supplementary material, and not part of the
+format definition itself.
+\eb
+
 \textit{Online Form}
 
-In the online form, blue text is used to indicate hyperlinks.
+In the online form, 
+\bb
+\textcolor{blue}{blue text} 
+\eb
+is used to indicate hyperlinks.
 Most hyperlinks link to the definition of a term or
 construct, or to a cited Section or Figure.
 However, attributes
@@ -125,12 +140,15 @@ contains hyperlinks for the multiple usages.
 
 The occurrence of
 a DWARF name in its definition (or one of its definitions in the
-case of some attributes) is shown in \definition{color}. Other
-occurrences of the same name in the same or possibly following
+case of some attributes) is shown in 
+\bb
+\definition{this color}. 
+\eb
+Other occurrences of the same name in the same or possibly following
 paragraphs are generally in normal text color.)
 
-The Table of Contents, List of Figures, List of Tables and Index provide hyperlinks to the 
-respective items and places.
+The Table of Contents, List of Figures, List of Tables and Index 
+provide hyperlinks to the respective items and places.
 
 \textit{Paper Form}
 
index 270481d..7351e2e 100644 (file)
@@ -100,8 +100,11 @@ described in Chapters 3, 4 and 5.
 \end{table}
 
 
-\textit{The debugging information entry descriptions 
-in Sections 3, 4 and 5 generally include mention of
+\textit{The debugging information entry descriptions in
+\bb
+Chapters
+\eb
+3, 4 and 5 generally include mention of
 most, but not necessarily all, of the attributes 
 that are normally or possibly used with the entry.
 Some attributes, whose applicability tends to be 
@@ -118,27 +121,21 @@ among others.}
 The debugging information entries are contained in the 
 \dotdebuginfo{} and/or \dotdebuginfodwo{} sections of an object file.
 
-\needlines{7}
+\needlines{4}
 Optionally, debugging information may be partitioned such
 that the majority of the debugging information can remain in
 individual object files without being processed by the
-linker. These debugging information entries are contained in
-the \dotdebuginfodwo{} sections. These
-sections may be placed in the object file but marked so that
-the linker ignores them, or they may be placed in a separate
-DWARF object file that resides alongside the normal object
-file. See Section \refersec{datarep:splitdwarfobjectfiles} and
+linker. 
+\bb\eb
+See Section \refersec{datarep:splitdwarfobjectfiles} and
 Appendix \refersec{app:splitdwarfobjectsinformative} for details.
 
+\needlines{4}
 As a further option, debugging information entries and other debugging
 information that are the same in multiple executable or shared object files 
 may be found in a separate \addtoindex{supplementary object file} that 
 contains supplementary debug sections.
-The executable or shared object file which contains references to
-those debugging information entries contain a \dotdebugsup{} section
-with information that identifies the \addtoindex{supplementary object file}; 
-the \addtoindex{supplementary object file} contains a variant of this same section
-that is used to unambiguously associate it with the referencing object.
+\bb\eb
 See Section \refersec{datarep:dwarfsupplemetaryobjectfiles} for
 further details.
  
@@ -239,10 +236,10 @@ The attributes are listed in Table \referfol{tab:attributenames}.
 \DWATbitstrideTARG{} 
 &\livelinki{chap:DWATbitstridearrayelementstrideofarraytype}
            {Array element stride (of array type)}
-           {array element stride (of array type)} \\
+           {array element stride (of array type)} \\*
 &\livelinki{chap:DWATbitstridesubrangestridedimensionofarraytype}
            {Subrange stride (dimension of array type)}
-           {subrange stride (dimension of array type)} \\
+           {subrange stride (dimension of array type)} \\*
 &\livelinki{chap:DWATbitstrideenumerationstridedimensionofarraytype}
            {Enumeration stride (dimension of array type)}
            {enumeration stride (dimension of array type)} \\
@@ -791,6 +788,7 @@ The attributes are listed in Table \referfol{tab:attributenames}.
 \addtoindexx{class of attribute value!string|see {string class}}
 \addtoindexx{class of attribute value!stroffsetsptr|see {stroffsetsptr class}}
 
+\needlines{6}
 The permissible values
 \addtoindexx{attribute value classes}
 for an attribute belong to one or more classes of attribute
@@ -801,8 +799,11 @@ of a single piece of constant data.
 \doublequote{Constant data}
 is the class of attribute value that those attributes may have. 
 There are several representations of constant data,
-however (one, two, four, or eight bytes, and variable length
-data). 
+\bb
+including fixed length data of one, two, four, eight or 16 bytes 
+in size, 
+\eb
+and variable length data). 
 The particular representation for any given instance
 of an attribute is encoded along with the attribute name as
 part of the information that guides the interpretation of a
@@ -832,10 +833,12 @@ to one of the classes shown in Table \referfol{tab:classesofattributevalue}.
 
 \hypertarget{chap:classaddrptr}{}
 \livelinki{datarep:classaddrptr}{addrptr}{addrptr class}
-&Refers to a base location in the DWARF section that holds
-a series of machine address values. Certain attributes \mbox{refer}
-one of these addresses by indexing relative to this base
-location.
+&
+\bb
+Specifies a location in the DWARF section that holds
+a series of machine address values. Certain attributes use
+one of these addresses by indexing relative to this location.
+\eb
 \\
 
 \hypertarget{chap:classblock}{}
@@ -845,15 +848,13 @@ location.
  
 \hypertarget{chap:classconstant}{}
 \livelinki{datarep:classconstant}{constant}{constant class}
-&One, two, four or eight bytes of uninterpreted data, or data
+&One, two, four, eight 
+\bb
+or sixteen 
+\eb
+bytes of uninterpreted data, or data
 encoded in the variable length format known as LEB128 
 (see Section \refersec{datarep:variablelengthdata}).
-
-\textit{Most constant values are integers of one kind or
-another (codes, offsets, counts, and so on); these are
-sometimes called \doublequote{integer constants} for emphasis.}
-\addtoindexx{integer constant}
-\addtoindexx{constant class!integer}
 \\
 
 \hypertarget{chap:classexprloc}{}
@@ -868,29 +869,45 @@ sometimes called \doublequote{integer constants} for emphasis.}
 
 \hypertarget{chap:classlineptr}{}
 \livelinki{datarep:classlineptr}{lineptr}{lineptr class}
-&Refers to a location in the DWARF section that holds line number information.
+&
+\bb
+Specifies
+\eb
+a location in the DWARF section that holds line number information.
 \\
 
 \hypertarget{chap:classloclistptr}{}
 \livelinki{datarep:classloclistptr}{loclistptr}{loclistptr class}
-&Refers to a location in the DWARF section that holds \mbox{location} lists, which
+&
+\bb
+Specifies
+\eb
+a location in the DWARF section that holds \mbox{location} lists, which
 describe objects whose location can change during their lifetime.
 \\
 
 \hypertarget{chap:classmacptr}{}
 \livelinki{datarep:classmacptr}{macptr}{macptr class}
-& Refers to a location in the DWARF section that holds macro definition
- information.
+&
+\bb
+Specifies 
+\eb
+a location in the DWARF section that holds macro definition
+information.
 \\
 
 \hypertarget{chap:classrangelistptr}{}
 \livelinki{datarep:classrangelistptr}{rangelistptr}{rangelistptr class}
-& Refers to a location in the DWARF section that holds non\dash contiguous address ranges.
+&
+\bb
+Specifies 
+\eb
+a location in the DWARF section that holds non-contiguous address ranges.
 \\
 
 \hypertarget{chap:classreference}{}
 \livelinki{datarep:classreference}{reference}{reference class}
-& Refers to one of the debugging information
+&Refers to one of the debugging information
 entries that \mbox{describe} the program.  There are four types of
 \mbox{reference}. The first is an offset relative to the beginning
 of the \mbox{compilation} unit in which the reference occurs and must
@@ -900,7 +917,11 @@ entry in any compilation unit, including one different from
 the unit containing the reference. The third type of reference
 is an indirect reference to a 
 \addtoindexx{type signature}
-type definition using a 8-byte \mbox{signature} 
+type definition using 
+\bb
+an 
+\eb
+8-byte \mbox{signature} 
 for that type. The fourth type of reference is a reference from within the 
 \dotdebuginfo{} section of the executable or shared object file to
 a debugging information entry in the \dotdebuginfo{} section of 
@@ -909,8 +930,8 @@ a \addtoindex{supplementary object file}.
 
 \hypertarget{chap:classstring}{}
 \livelinki{datarep:classstring}{string}{string class}
-& A null\dash terminated sequence of zero or more
-(non\dash null) bytes. Data in this class are generally
+& A null-terminated sequence of zero or more
+(non-null) bytes. Data in this class are generally
 printable strings. Strings may be represented directly in
 the debugging \mbox{information} entry or as an offset in a separate
 string table.
@@ -918,10 +939,22 @@ string table.
 
 \hypertarget{chap:classstroffsetsptr}{}
 \livelinki{datarep:classstroffsetsptr}{stroffsetsptr}{stroffsetsptr class}
-&Refers to a base location in the DWARF section that holds
-a series of offsets in the DWARF section that holds strings.
-Certain attributes refer to one of these offsets by indexing 
-\mbox{relative} to this base location. The resulting offset is then 
+&
+\bb
+Specifies a
+\eb
+location in the DWARF section that holds
+a series of offsets 
+\bb
+into 
+\eb
+the DWARF section that holds strings.
+Certain attributes 
+\bb
+use 
+\eb
+one of these offsets by indexing 
+\mbox{relative} to this location. The resulting offset is then 
 used to index into the DWARF string section.
 \\
 
@@ -951,11 +984,9 @@ The ownership relation
 \addtoindexx{debugging information entry!ownership relation}
 of debugging
 information entries is achieved naturally because the debugging
-information is represented as a tree. 
-The nodes of the tree
+information is represented as a tree. The nodes of the tree
 are the debugging information entries themselves. 
-The child
-entries of any node are exactly those debugging information
+The child entries of any node are exactly those debugging information
 entries owned by that node.  
 
 \needlines{4}
@@ -996,19 +1027,16 @@ to any debugging information entry.
 The value of this attribute is a reference to the sibling entry
 of the entry to which the attribute is attached.
 
-
-\section{Target Addressable Units and Addresses}
+\bb
+\section{Target Addresses}
 \label{chap:targetaddressableunitsandaddresses}
-The standard assumes that the smallest directly 
-\addtoindex{addressable unit} of memory on the
-target architecture is a byte consisting of eight bits.
-
 \label{chap:targetaddresses}
-Many places in this document refer to the size of an
+\eb
+\addtoindexx{size of an address}
 \addtoindexx{size of an address|see{\textit{also} \texttt{address\_size}}}
-\addtoindexi{address}{size of an address}
 \addtoindexx{address size|see{size of an address}}
 \addtoindexx{address size|see{\textit{also} \texttt{address\_size}}}
+Many places in this document refer to the size of an address
 on the target architecture (or equivalently, target machine)
 to which a DWARF description applies. For processors which
 can be configured to have different address sizes or different
@@ -1025,27 +1053,30 @@ code generated for one or the other of these
 \addtoindexx{size of an address}
 address sizes. In
 that case, the DWARF debugging information contained in this
-object file will use the same address size.
-}
+object file will use the same address size.}
 
-\textit{%
-Architectures which have multiple instruction sets are
-supported by the \texttt{isa} entry in the line number information
-(see Section \refersec{chap:statemachineregisters}).
-}
+\bbpareb
 
 \needlines{4}
 \section{DWARF Expressions}
 \label{chap:dwarfexpressions}
-DWARF expressions describe how to compute a value or name a
-location during debugging of a program. 
+DWARF expressions describe how to compute a value or 
+\bb
+specify a location.
+\eb
 They are expressed in
 terms of DWARF operations that operate on a stack of values.
 
-All DWARF operations are encoded as a stream of opcodes that
-are each followed by zero or more literal operands. 
-The number
-of operands is determined by the opcode.  
+\bb
+A DWARF expression is encoded as a stream of operations, 
+each consisting of an opcode
+\eb
+followed by zero or more literal operands. 
+The number of operands is 
+\bb
+implied 
+\eb
+by the opcode.  
 
 In addition to the
 general operations that are defined here, operations that are
@@ -1059,7 +1090,7 @@ a simple stack machine.
 Each element of the stack has a type and a value, and can represent
 a value of any supported base type of the target machine.  Instead of
 a base type, elements can have a 
-\livetarg{chap:specialaddresstype}{special address type},
+\definitionx{special address type}\livetarg{chap:specialaddresstype}{},
 which is an integral type that has the 
 \addtoindex{size of an address} on the target machine and 
 unspecified signedness. The value on the top of the stack after 
@@ -1071,25 +1102,7 @@ taken to be the result (the address of the object, the
 value of the array bound, the length of a dynamic string,
 the desired value itself, and so on).
 
-\needlines{4}
-\textit{While the abstract definition of the stack calls for variable-size entries
-able to hold any supported base type, in practice it is expected that each
-element of the stack can be represented as a fixed-size element large enough
-to hold a value of any type supported by the DWARF consumer for that target,
-plus a small identifier sufficient to encode the type of that element.
-Support for base types other than what is required to do address arithmetic
-is intended only for debugging of optimized code, and the completeness of the
-DWARF consumer's support for the full set of base types is a
-quality-of-implementation issue. If a consumer encounters a DWARF expression
-that uses a type it does not support, it should ignore the entire expression
-and report its inability to provide the requested information.}
-
-\textit{It should also be noted that floating-point arithmetic is highly dependent
-on the computational environment. It is not the intention of this expression
-evaluation facility to produce identical results to those produced by the
-program being debugged while executing on the target machine. Floating-point
-computations in this stack machine will be done with precision control and
-rounding modes as defined by the implementation.}
+\bbpareb
 
 \needlines{4}
 \subsubsection{Literal Encodings}
@@ -1123,6 +1136,7 @@ The single operand of a \DWOPconstnuNAME{} operation provides a 1,
 The single operand of a \DWOPconstnsNAME{} operation provides a 1,
 2, 4, or 8-byte signed integer constant, respectively.
 
+\needlines{4}
 \itembfnl{\DWOPconstuTARG}
 The single operand of the \DWOPconstuNAME{} operation provides
 an unsigned LEB128\addtoindexx{LEB128!unsigned} integer constant.
@@ -1163,8 +1177,11 @@ information entry in the current compilation unit, which must be a
 \DWTAGbasetype{} entry that provides the type of the constant provided. The
 second operand is 1-byte unsigned integer that specifies the size of the
 constant value, which is the same as the size of the base type referenced
-by the first operand. The third operand is a block of specified 
-size that is to be interpreted as a value of the referenced type.
+by the first operand. The third operand is a 
+\bb
+sequence of bytes of the given size that is 
+\eb
+interpreted as a value of the referenced type.
 
 \textit{While the size of the constant can be inferred from the base type
 definition, it is encoded explicitly into the operation so that the
@@ -1191,16 +1208,19 @@ signed offset together with the \specialaddresstype.
 The \DWOPfbregNAME{} operation provides a 
 signed LEB128\addtoindexx{LEB128!signed} offset
 from the address specified by the location description in the
-\DWATframebase{} attribute of the current function. (This
-is typically a \doublequote{stack pointer} register plus or minus
-some offset. On more sophisticated systems it might be a
-location list that adjusts the offset according to changes
-in the stack pointer as the PC changes.)
+\DWATframebase{} attribute of the current function.
+\bb
+\textit{This is typically a stack pointer register plus or minus some offset.}
+\eb
 
 \itembfnl{\DWOPbregzeroTARG, \DWOPbregoneTARG, \dots, \DWOPbregthirtyoneTARG}
 The single operand of the \DWOPbregnTARG{} 
 operations provides
 a signed LEB128\addtoindexx{LEB128!signed} offset from
+\bb
+the contents of
+\eb
 the specified register.
 
 \itembfnl{\DWOPbregxTARG}
@@ -1232,18 +1252,9 @@ operations manipulate the DWARF stack. Operations
 that index the stack assume that the top of the stack (most
 recently added entry) has index 0.
 
-The \DWOPdup{}, \DWOPdrop{}, \DWOPpick{}, \DWOPover{}, \DWOPswap{}
-and \DWOProt{} operations manipulate the elements of the stack as pairs
-consisting of the value together with its type identifier. 
-The \DWOPderef{}, \DWOPderefsize{}, \DWOPxderef{}, \DWOPxderefsize{} 
-and \DWOPformtlsaddress{}
-operations require the popped values to have an integral type, either the
-\specialaddresstype{} or some other integral base type, and push a 
-value with the \specialaddresstype.  
-\DWOPdereftype{} and \DWOPxdereftype{} operations have the
-same requirement on the popped values, but push a value together 
-with the same type as the popped values.
-All other operations push a value together with the \specialaddresstype.
+\bb
+Each entry on the stack has an associated type.
+\eb
 
 \needlines{4}
 \begin{enumerate}[1. ]
@@ -1285,21 +1296,25 @@ becomes the second entry.
 \itembfnl{\DWOPderefTARG}
 The \DWOPderefNAME{} operation pops the top stack entry and 
 treats it as an address. The popped value must have an integral type.
-The value retrieved from that address is pushed, together with the
-\specialaddresstype{} identifier. 
+The value retrieved from that address is pushed, 
+\bb
+and has the \specialaddresstype{}.
+\eb 
 The size of the data retrieved from the 
 \addtoindexi{dereferenced}{address!dereference operator}
 address is the \addtoindex{size of an address} on the target machine.
 
-\needlines{4}
+\needlines{6}
 \itembfnl{\DWOPderefsizeTARG}
 The \DWOPderefsizeNAME{} operation behaves like the 
 \DWOPderef{}
 operation: it pops the top stack entry and treats it as an
 address. The popped value must have an integral type.
-The value retrieved from that address is pushed, together with the
-\specialaddresstype{} identifier. In
-the \DWOPderefsizeNAME{} operation, however, the size in bytes
+The value retrieved from that address is pushed,
+\bb
+and has the \specialaddresstype{}.
+\eb 
+In the \DWOPderefsizeNAME{} operation, however, the size in bytes
 of the data retrieved from the dereferenced address is
 specified by the single operand. This operand is a 1-byte
 unsigned integral constant whose value may not be larger
@@ -1344,6 +1359,7 @@ The size of the data retrieved from the
 \addtoindexi{dereferenced}{address!dereference operator}
 address is the size of the \specialaddresstype.
 
+\needlines{4}
 \itembfnl{\DWOPxderefsizeTARG}
 The \DWOPxderefsizeNAME{} operation behaves like the
 \DWOPxderef{} operation. The entry at the top of the stack is
@@ -1459,14 +1475,18 @@ space efficient to reference that.}
 \textit{Examples illustrating many of these stack operations are
 found in Appendix \refersec{app:dwarfstackoperationexamples}.}
 
+\needlines{4}
 \subsubsection{Arithmetic and Logical Operations} 
 \addtoindexx{DWARF expression!arithmetic operations}
 \addtoindexx{DWARF expression!logical operations}
-The following provide arithmetic and logical operations.  If an operation
-pops two values from the stack, both values must have the same type,
+The following provide arithmetic and logical operations. 
+\bb
+Operands of an operation with two operands
+\eb
+must have the same type,
 either the same base type or both the \specialaddresstype.
 The result of the operation which is pushed back has the same type
-as the type of the operands.  
+as the type of the operand(s).  
 
 If the type of the operands is the \specialaddresstype, 
 except as otherwise specified, the arithmetic operations
@@ -1509,6 +1529,7 @@ calculation: former second stack entry modulo the former top of the stack.
 The \DWOPmulNAME{} operation pops the top two stack entries, multiplies them together, and
 pushes the result.
 
+\needlines{4}
 \itembfnl{\DWOPnegTARG}
 The \DWOPnegNAME{} operation pops the top stack entry, interprets
 it as a signed value and pushes its negation. If the negation
@@ -1530,7 +1551,12 @@ adds them together, and pushes the result.
 \itembfnl{\DWOPplusuconstTARG}
 The \DWOPplusuconstNAME{} operation pops the top stack entry,
 adds it to the unsigned LEB128\addtoindexx{LEB128!unsigned}
-constant operand and pushes the result.
+constant operand 
+\bb
+interpreted as the same type as the operand popped from the 
+top of the stack
+\eb
+and pushes the result.
 
 \textit{This operation is supplied specifically to be
 able to encode more field offsets in two bytes than can be
@@ -1574,7 +1600,7 @@ following operations provide simple control of the flow of a DWARF expression.
 \itembfnl{\DWOPleTARG, \DWOPgeTARG, \DWOPeqTARG, \DWOPltTARG, \DWOPgtTARG, \DWOPneTARG}
 The six relational operators each:
 \begin{itemize}
-\item pop the top two stack values, which should both have the same type,
+\item pop the top two stack values, which \bb\eb have the same type,
 either the same base type or both the \specialaddresstype, 
 
 \item compare the operands:
@@ -1589,9 +1615,6 @@ The pushed value has the \specialaddresstype.
 
 If the operands have the \specialaddresstype, the comparisons  
 are performed as signed operations.
-The six operators are \DWOPleNAME{} (less than or equal to), \DWOPgeNAME{}
-(greater than or equal to), \DWOPeqNAME{} (equal to), \DWOPltNAME{} (less
-than), \DWOPgtNAME{} (greater than) and \DWOPneNAME{} (not equal to).
 
 \needlines{6}
 \itembfnl{\DWOPskipTARG}
@@ -1638,11 +1661,9 @@ must be performed by the consumer.
 \DWOPcalltwo, \DWOPcallfour{} and \DWOPcallref{} is exactly like
 that for \DWFORMreftwo, \DWFORMreffour{} and \DWFORMrefaddr,
 respectively  
-(see Section  \refersec{datarep:attributeencodings}).  
-}
+(see Section  \refersec{datarep:attributeencodings}).}
 
-These operations transfer
-control of DWARF expression evaluation to 
+These operations transfer control of DWARF expression evaluation to 
 \addtoindexx{location attribute}
 the 
 \DWATlocation{}
@@ -1708,10 +1729,13 @@ in bytes of the block.  If the block contains a register location
 description, \DWOPentryvalueNAME{} pushes the value that register had upon
 entering the current subprogram.  If the block contains a DWARF expression,
 the DWARF expression is evaluated as if it has been evaluated upon entering
-the current subprogram.  The DWARF expression should not assume any values
-being present on the DWARF stack initially and should result in exactly one
-value being pushed on the DWARF stack when completed.  That value is the value
-being pushed by the \DWOPentryvalueNAME{} operation.  
+the current subprogram.  The DWARF expression 
+\bb
+assumes no values are present on the DWARF stack initially and results
+\eb
+in exactly one
+value being pushed on the DWARF stack when completed.
+\bb\eb 
 
 \DWOPpushobjectaddress{} is not meaningful inside of this DWARF operation.
 
@@ -1732,7 +1756,7 @@ register or memory values during \DWOPentryvalueNAME{} evaluation.}
 
 \end{enumerate}
 
-\needlines{5}
+\needlines{8}
 \section{Location Descriptions}
 \label{chap:locationdescriptions}
 \textit{Debugging information 
@@ -1767,22 +1791,7 @@ as its lifetime is either static or the same as the
 \livelink{chap:lexicalblock}{lexical block} that owns it, 
 and it does not move during its lifetime.
 
-Single location descriptions are of two kinds:
-\begin{enumerate}[a) ]
-\item Simple location descriptions, which describe the location
-\addtoindexx{location description!simple}
-of one contiguous piece (usually all) of an object. A simple
-location description may describe a location in addressable
-memory, or in a register, or the lack of a location (with or
-without a known value).
-
-\item  Composite location descriptions, which describe an
-\addtoindexx{location description!composite}
-object in terms of pieces each of which may be contained in
-part of a register or stored in a memory location unrelated
-to other pieces.
-
-\end{enumerate}
+\bbpareb
 
 \needlines{4}
 \item \textit{Location lists}, which are used to 
@@ -1809,7 +1818,6 @@ separate
 \addtoindexx{location list}
 location list table).
 
-\needlines{8}
 \subsection{Single Location Descriptions}
 A single location description is either:
 \begin{enumerate}[1. ]
@@ -1825,8 +1833,8 @@ one composition operation. Each simple location description
 describes the location of one piece of the object; each
 composition operation describes which part of the object is
 located there. Each simple location description that is a
-DWARF expression is evaluated independently of any others
-(as though on its own separate stack, if any). 
+DWARF expression is evaluated independently of any others.
+\bb\eb
 \end{enumerate}
 
 
 simple location description consists of one 
 contiguous piece or all of an object or value.
 
+\bb
+\needlines{4}
+\subsubsubsection{Empty Location Descriptions}
+An \addtoindex{empty location description}
+consists of a DWARF expression
+\addtoindexx{location description!empty}
+containing no operations. It represents a piece or all of an
+object that is present in the source but not in the object code
+(perhaps due to optimization).
+\eb
 
 \subsubsubsection{Memory Location Descriptions}
 A 
 \addtoindexx{location description!memory}
 memory location description 
 \addtoindexx{memory location description}
-consists of a non\dash empty DWARF
+consists of a non-empty DWARF
 expression (see 
-Section \refersec{chap:dwarfexpressions}
-), whose value is the address of
+Section \refersec{chap:dwarfexpressions}), 
+whose value is the address of
 a piece or all of an object or other entity in memory.
 
 \subsubsubsection{Register Location Descriptions}
@@ -1866,8 +1884,10 @@ register location description must stand alone as the entire
 description of an object or a piece of an object.
 }
 
-The following DWARF operations can be used to name a register.
-
+The following DWARF operations can be used to 
+\bb
+specify a register location.
+\eb
 
 \textit{Note that the register number represents a DWARF specific
 mapping of numbers onto the actual registers of a given
@@ -1908,14 +1928,12 @@ that has no location in the program but is a known constant
 or is computed from other locations and values in the program.
 \begin{enumerate}[1. ]
 \itembfnl{\DWOPimplicitvalueTARG}
-The \DWOPimplicitvalueNAME{} 
-operation specifies an immediate value
+The \DWOPimplicitvalueNAME{} operation specifies an immediate value
 using two operands: an unsigned LEB128\addtoindexx{LEB128!unsigned}
-length, followed by
-%FIXME: should this block be a reference? To what?
-a \nolink{block} representing the value in the memory representation
-of the target machine. The length operand gives the length
-in bytes of the \nolink{block}.
+length, followed by a 
+\bb
+sequence of bytes of the given length that contain the value.
+\eb
 
 \itembfnl{\DWOPstackvalueTARG}
 The \DWOPstackvalueNAME{} 
@@ -1928,6 +1946,12 @@ actual value of the object, rather than its location. The
 
 \needlines{4}
 \itembfnl{\DWOPimplicitpointerTARG}
+\bb
+\textit{An optimizing compiler may eliminate a pointer, while
+still retaining the value that the pointer addressed.  
+\DWOPimplicitpointerNAME{} allows a producer to describe this value.}
+\eb
+
 The \DWOPimplicitpointerNAME{} operation specifies that the object
 is a pointer that cannot be represented as a real pointer,
 even though the value it would point to can be described. In
@@ -1983,14 +2007,7 @@ register but not in memory. The operations in this section are
 used to describe values that exist neither in memory nor in a
 single register.}
 
-\needlines{4}
-\subsubsubsection{Empty Location Descriptions}
-An \addtoindex{empty location description}
-consists of a DWARF expression
-\addtoindexx{location description!empty}
-containing no operations. It represents a piece or all of an
-object that is present in the source but not in the object code
-(perhaps due to optimization).
+\bbpareb
 
 \needlines{6}
 \subsubsection{Composite Location Descriptions}
@@ -2021,8 +2038,9 @@ the piece within that register is defined by the ABI.
 or store a variable partially in memory and partially in
 registers. \DWOPpieceNAME{} provides a way of describing how large
 a part of a variable a particular DWARF location description
-refers to. }
+refers to.}
 
+\needlines{4}
 \itembfnl{\DWOPbitpieceTARG}
 The \DWOPbitpieceNAME{} 
 operation takes two operands. The first
@@ -2034,7 +2052,9 @@ gives the offset in bits from the location defined by the
 preceding DWARF location description.  
 
 Interpretation of the
-offset depends on the kind of location description. If the
+offset depends on the 
+\bb\eb
+location description. If the
 location description is empty, the offset doesn\textquoteright t matter and
 the \DWOPbitpieceNAME{} operation describes a piece consisting
 of the given number of bits whose values are undefined. If
@@ -2065,8 +2085,9 @@ while the second is intended for use in a \splitDWARFobjectfile{}
 (see Section \refersec{datarep:splitdwarfobjectfiles}). The two
 forms are otherwise equivalent.
 
-\textit{The form for \splitDWARFobjectfile{s} is new in \DWARFVersionV.}
+\bbpareb
 
+\needlines{4}
 \subsubsection{Location Lists in Non-split Objects}
 \label{chap:locationlistsinnonsplitobjects}
 Location lists 
@@ -2160,7 +2181,12 @@ A \addtoindex{default location list entry} consists of:
 \item The value 0.
 \item The value of the largest representable address offset (for
       example, \wffffffff when the size of an address is 32 bits).
-\item A simple location description describing the location of the
+\item 
+\bb
+An unsigned 2-byte length describing the length of the location 
+      description that follows.
+\eb
+\item A \bb single \eb location description describing the location of the
       object when there is no prior normal location list entry
       that applies in the same location list.
 \end{enumerate}
@@ -2173,7 +2199,7 @@ A default location list entry must be the last location list
 entry of a location list except for the terminating end-of-list
 entry.
 
-A \addtoindex{default location list entry} describes a simple 
+A \addtoindex{default location list entry} describes a \bb single \eb 
 location which applies to all addresses which are not included 
 in any range defined earlier in the same location list.
 
@@ -2281,6 +2307,7 @@ given by this type of entry are not relative to the
 compilation unit base address. A single location
 description follows the fields that define the address range.
 
+\needlines{5}
 \itembfnl{\DWLLEstartlengthentryTARG}
 This entry contains one unsigned LEB128\addtoindexx{LEB128!unsigned}
 value and a 4-byte
@@ -2293,7 +2320,11 @@ This index is relative to the value of the
 The starting address given by this
 type of entry is not relative to the compilation unit
 base address. The second value is the
-length of the range. A single location
+length of the range
+\bb
+in bytes. 
+\eb
+A single location
 description follows the fields that define the address range.
 
 \itembfnl{\DWLLEoffsetpairentryTARG}
@@ -2307,7 +2338,7 @@ description follows the fields that define the address range.
 
 \needlines{4}
 \textit{The \DWLLEbaseaddressselectionentry, \DWLLEstartendentry{}
-and \DWLLEstartlengthentry entries obtain addresses within the 
+and \DWLLEstartlengthentry{} entries obtain addresses within the 
 target program indirectly using an index (not an offset) into an 
 array of addresses. The base of that array is obtained using the 
 \DWATaddrbase{} attribute of the containing compilation unit. 
@@ -2329,11 +2360,13 @@ user-defined type, such as an array, structure or enumeration.
 Alternatively, the entry referenced may describe a type
 modifier, such as constant, packed, pointer, reference or
 volatile, which in turn will reference another entry describing
-a type or type modifier (using 
-\addtoindexx{type attribute}
-a \DWATtypeNAME{} attribute of its
+a type or type modifier (using a
+\DWATtypeNAME{} attribute\addtoindexx{type attribute} of its
 own). See 
-Section  \referfol{chap:typeentries} 
+\bb
+Chapter 
+\eb
+\referfol{chap:typeentries} 
 for descriptions of the entries describing
 base types, user-defined types and type modifiers.
 
@@ -2412,8 +2445,6 @@ Table \refersec{tab:virtualitycodes}.
 \textit{A compiler may wish to generate debugging information entries
 for objects or types that were not actually declared in the
 source of the application. An example is a formal parameter
-%FIXME: The word 'this' should be rendered like a variant italic,
-%FIXME: not as a quoted name. Changed to tt font--RB
 entry to represent the hidden 
 \texttt{this} parameter\index{this parameter@\texttt{this} parameter}
 that most \addtoindex{C++} implementations pass as the first argument 
@@ -2614,19 +2645,11 @@ entry
 \hypertarget{chap:DWATdecllinelinenumberofsourcedeclaration}{}
 representing 
 \hypertarget{chap:DWATdeclcolumncolumnpositionofsourcedeclaration}{}
-the
-\addtoindexx{line number of declaration}
-declaration of an object, module, subprogram or
-\addtoindex{declaration column attribute}
-type 
-\addtoindex{declaration file attribute}
-may 
-\addtoindex{declaration line attribute}
-have
-\DWATdeclfileDEFN, 
-\DWATdecllineDEFN{} and 
-\DWATdeclcolumnDEFN{}
-attributes each of whose value is an unsigned
+the declaration of an object, module, subprogram or type may have
+\DWATdeclfileDEFN,\addtoindexx{declaration file attribute} 
+\DWATdecllineDEFN\addtoindexx{declaration line attribute} and 
+\DWATdeclcolumnDEFN\addtoindexx{declaration column attribute}
+attributes, each of whose value is an unsigned
 \livelink{chap:classconstant}{integer constant}.
 
 The value of 
@@ -2667,6 +2690,9 @@ representing
 a program entity that has been given a name may have a 
 \DWATnameDEFN{} 
 attribute\addtoindexx{name attribute}, whose value of 
+\bb
+class 
+\eb
 \CLASSstring{} represents the name as it appears in
 the source program. A debugging information entry containing
 no name attribute, or containing a name attribute whose value
@@ -2705,7 +2731,8 @@ whose value is a location description
 A 
 \addtoindex{DWARF procedure}
 is represented by any
-kind of debugging information entry that has a
+\bb\eb
+debugging information entry that has a
 \addtoindexx{location attribute}
 \DWATlocationNAME{}
 attribute. 
@@ -2758,8 +2785,10 @@ for a non-contiguous range of addresses.
 
 In addition, a non-contiguous range of 
 addresses may also be specified for the
-\DWATstartscope{} attribute.
-\addtoindexx{start scope attribute}
+\DWATstartscope{} attribute\addtoindexx{start scope attribute}
+\bb
+(see Section \refersec{chap:dataobjectentries}).
+\eb
 
 If an entity has no associated machine code, 
 none of these attributes are specified.
@@ -2768,34 +2797,24 @@ none of these attributes are specified.
 When there is a single address associated with an entity,
 such as a label or alternate entry point of a subprogram,
 the entry has a \DWATlowpc{} attribute whose value is the
-relocated address for the entity.
+\bb\eb address for the entity.
 
-\textit{While the \DWATentrypc{}
-attribute might also seem appropriate for this purpose,
-historically the \DWATlowpc{} attribute was used before
-\DWATentrypc{} was introduced 
-(in \addtoindex{DWARF Version 3}). There is
-insufficient reason to change this;
-\DWATlowpc{} serves as a default entry PC address as described
-in Section \refersec{chap:entryaddress}.}
+\bbpareb
 
 \needlines{8}
-\subsection{Continuous Address Range}
+\bb
+\subsection{Contiguous Address Range}
+\eb
 \label{chap:contiguousaddressranges}
 When the set of addresses of a debugging information entry can
 be described as a single contiguous range, the entry 
 \addtoindexx{high PC attribute}
 may 
 \addtoindexx{low PC attribute}
-have
-a \DWATlowpc{} and 
-\DWAThighpc{} pair of attributes. 
-The value
-of the 
-\DWATlowpc{} attribute 
-is the relocated address of the
+have a \DWATlowpc{} and \DWAThighpc{} pair of attributes. 
+The value of the \DWATlowpc{} attribute is the \bb\eb address of the
 first instruction associated with the entity. If the value of
-the \DWAThighpc{} is of class address, it is the relocated
+the \DWAThighpc{} is of class address, it is the \bb\eb
 address of the first location past the last instruction
 associated with the entity; if it is of class constant, the
 value is an unsigned integer offset which when added to the
@@ -2809,30 +2828,37 @@ may be beyond the last valid instruction in the executable.}
 The presence of low and high PC attributes for an entity
 implies that the code generated for the entity is contiguous
 and exists totally within the boundaries specified by those
-two attributes. If that is not the case, no low and high PC
-attributes should be produced.
+two attributes.
+\bb\eb
 
 \subsection{Non-Contiguous Address Ranges}
 \label{chap:noncontiguousaddressranges}
 When the set of addresses of a debugging information entry
 \addtoindexx{non-contiguous address ranges}
-cannot be described as a single contiguous range, the entry has
-a \DWATranges{} attribute 
-\addtoindexx{ranges attribute}
+cannot be described as a single contiguous range, the entry 
+\bb
+may have
+\eb
+a \DWATranges{} attribute\addtoindexx{ranges attribute}
 whose value is of class \livelink{chap:classrangelistptr}{rangelistptr}
 and indicates the beginning of a \addtoindex{range list}.
 Similarly,
-a \DWATstartscope{} attribute 
-\addtoindexx{start scope attribute}
+a \DWATstartscope{} attribute\addtoindexx{start scope attribute}
+\bb
+(see Section \refersec{chap:dataobjectentries}).
+\eb
 may have a value of class
 \livelink{chap:classrangelistptr}{rangelistptr} for the same reason.  
 
-Range lists are contained in a separate object file section called 
-\dotdebugranges{}. A
-\addtoindex{range list} is indicated by a 
-\DWATranges{} attribute whose
-\addtoindexx{ranges attribute}
-value is represented as an offset from the beginning of the
+Range lists are contained in 
+\bb
+the \dotdebugranges{} section. 
+\eb
+A \addtoindex{range list} is indicated by a 
+\DWATranges{} attribute\addtoindexx{ranges attribute}
+whose value is 
+\bb\eb
+an offset from the beginning of the
 \dotdebugranges{} section to the beginning of the 
 \addtoindex{range list}.
 
@@ -2843,11 +2869,7 @@ offset within the \dotdebugranges{} section for the compilation
 unit. The offset given by the \DWATranges{} attribute is
 relative to that base.
 
-\textit{The \DWATrangesbase{} attribute is new in \DWARFVersionV.
-The advantage of this attribute is that it reduces the number of
-object language relocations needed for references to the \dotdebugranges{}
-section from one for each range entry to a single relocation that
-applies for the entire compilation unit.}
+\bbpareb
 
 The \addtoindex{applicable base address} of a \addtoindex{range list} 
 entry is determined
@@ -2910,7 +2932,11 @@ of subsequent entries of the location list.
 \end{enumerate}
 
 \textit{A base address selection entry affects only the 
-remainder of list in which it is contained.}
+remainder of 
+\bb
+the 
+\eb
+list in which it is contained.}
 
 \subsubsection{End-of-List Entry}
 The end of any given \addtoindex{range list} is marked by an 
@@ -2946,11 +2972,19 @@ module initialization, subroutines,
 \livelink{chap:tryandcatchblockentries}{try/catch \nolink{blocks}},
 and the like, may have a \DWATentrypcDEFN{} attribute 
 \addtoindexx{entry PC address}
-to indicate the first executable instruction within that 
+to indicate the 
+\bb
+instruction where execution should begin
+\eb
+within that 
 range\hypertarget{chap:entryaddressofscope}{}
-of addresses. The value of the \DWATentrypcNAME{} attribute is a
-relocated address if the
-value of \DWATentrypcNAME{} is of class \CLASSaddress; or if it is of class
+of addresses. 
+\bb
+If the value of the \DWATentrypcNAME{} attribute is of
+class \CLASSaddress{} that address is the entry address;
+or, 
+\eb
+if it is of class
 \CLASSconstant, the value is an unsigned integer offset which, when
 added to the base address of the function, gives the entry
 address. 
@@ -2975,28 +3009,31 @@ computed dynamically during execution.
 The value of these
 attributes is determined based on the class as follows:
 \begin{itemize}
-\item For a \livelink{chap:classconstant}{constant}, the value of the constant is the value of
-the attribute.
+\item For a \livelink{chap:classconstant}{constant}, the value 
+of the constant is the value of the attribute.
 
 \item For a \livelink{chap:classreference}{reference}, the
-value is a reference to another DIE.  This DIE may:
+value is a reference to another 
+\bb
+debugging information entry.  This entry may:
+\eb
 \begin{itemize}
 \renewcommand{\itemsep}{0cm}
 \item describe a constant which is the attribute value,
 \item describe a variable which contains the attribute value, or
-\item contain a DWARF expression which computes the attribute value
-      (for example, be a \DWTAGdwarfprocedure{} entry).
+\item 
+\bb
+      contain a \DWATlocation{} attribute whose value is a \eb
+      DWARF expression which computes the attribute value
+      (for example, \bb\eb a \DWTAGdwarfprocedure{} entry).
 \end{itemize}
 
-\item For an \livelink{chap:classexprloc}{exprloc}, the value is interpreted as a 
-DWARF expression; 
-evaluation of the expression yields the value of
-the attribute.
+\item For an \livelink{chap:classexprloc}{exprloc}, the value 
+is interpreted as a DWARF expression; evaluation of the expression 
+yields the value of the attribute.
 \end{itemize}
 
-\textit{Whether an attribute value can be dynamic depends on the
-rules of the applicable programming language.
-}
+\bbpareb
 
 \needlines{4}
 \section{Entity Descriptions}
@@ -3062,15 +3099,14 @@ associated distinct linkage name it may sometimes be useful
 for a producer to include this name in the DWARF description
 of the program to facilitate consumer access to and use of
 object file information about an entity and/or information
-\hypertarget{chap:DWATlinkagenameobjectfilelinkagenameofanentity}{}
 that is encoded in the linkage name itself.  
 }
 
 % Some trouble maybe with hbox full, so we try optional word breaks.
 A debugging information entry may have a
-\addtoindexx{linkage name attribute}
-\DWATlinkagenameDEFN{}
-attribute whose value is a null-terminated string containing the 
+\DWATlinkagenameDEFN{}\hypertarget{chap:DWATlinkagenameobjectfilelinkagenameofanentity}{}
+attribute\addtoindexx{linkage name attribute}
+whose value is a null-terminated string containing the 
 object file linkage name associated with the corresponding entity.
 
 
@@ -3141,13 +3177,12 @@ single location description for the run-time constant address.
 \livetarg{chap:DWATalignmentnondefault}{}
 A debugging information entry may have a 
 \DWATalignmentDEFN{} attribute\addtoindexx{alignment attribute}
-that describes the (non-default) alignment requirements of the entry.
-\DWATalignment{} has a positive, non-zero, integer constant value
-describing the strictest specified (non-default) alignment of the entity. 
-This constant describes the actual alignment used by the compiler.
-(If there are multiple alignments specified by the user, or if the 
-user specified an alignment the compiler could not satisfy, then 
-only the strictest alignment is added using this attribute.)
+\bb
+whose value of class \CLASSconstant{} is
+a positive, non-zero, integer describing the 
+\eb 
+alignment of the entity. 
+\bb\eb
 
 \textit{For example, an alignment attribute whose value is 8 indicates
 that the entity to which it applies occurs at an address that is a
index 8c947b3..795b5dd 100644 (file)
@@ -55,25 +55,36 @@ content of the debugging entries. The second piece is the
 way the debugging information is encoded and represented in
 an object file.
 
-The informational content is described in 
-Sections \ref{chap:generaldescription} 
+The informational content is described in
+\bb 
+Chapters
+\eb
+\ref{chap:generaldescription} 
 through
 \ref{chap:otherdebugginginformation}. 
-Section  \ref{chap:generaldescription}
+Chapter \ref{chap:generaldescription}
 describes the overall structure of the information
-and attributes that is common to many or all of the different
+and attributes that are common to many or all of the different
 debugging information entries. 
-Sections \ref{chap:programscopeentries}, 
+\bb
+Chapters
+\eb \ref{chap:programscopeentries}, 
 \ref{chap:dataobjectandobjectlistentries} and 
 \ref{chap:typeentries} describe
 the specific debugging information entries and how they
 communicate the necessary information about the source program
 to a debugger. 
-Section \ref{chap:otherdebugginginformation} 
+\bb
+Chapter
+\eb
+\ref{chap:otherdebugginginformation} 
 describes debugging information
 contained outside of the debugging information entries. The
 encoding of the DWARF information is presented in 
-Section \ref{datarep:datarepresentation}.
+\bb
+Chapter
+\eb
+\ref{datarep:datarepresentation}.
 
 This organization closely follows that used in the 
 \DWARFVersionIV{} document. Except where needed to incorporate
@@ -88,7 +99,6 @@ format definition itself. The several appendices consist only
 of explanatory or supplementary material, and are not part
 of the formal definition.
 
-\bb
 \section{Objectives and Rationale}
 
 DWARF has had a set of objectives since its inception which have 
@@ -99,7 +109,9 @@ understanding of the DWARF Debugging Format.
 Although DWARF Version 1 was developed in the late 1980's as a 
 format to support debugging C programs written for AT\&T hardware 
 running SVR4, \DWARFVersionII{} and later has evolved far beyond 
-this origin. One difference between DWARF and other object formats 
+this origin. One difference between DWARF and other 
+\bb\eb
+formats 
 is that the latter are often specific to a particular language, 
 architecture, and/or operating system. 
 
@@ -121,7 +133,8 @@ particular language and which doesn't appear to have more
 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{} DIE, which is 
+An example of this is the \DWTAGconditionNAME{} DIE, 
+\bb\eb 
 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 
@@ -149,7 +162,10 @@ systems like BSD and Linux.  DWARF fits well with the section
 organization of the ELF object file format. Nonetheless, DWARF 
 attempts to be independent of either the OS or the object file 
 format.  There have been implementations of DWARF debugging 
-data in OMF or COFF object files. 
+data in 
+\bb
+COFF, Mach-O and other object file formats. 
+\eb
 
 DWARF assumes that any object file format will be able to 
 distinguish the various DWARF data sections in some fashion, 
@@ -157,9 +173,9 @@ preferably by name.
 
 DWARF makes a few assumptions about functionality provided by 
 the underlying operating system.  DWARF data sections can be 
-read sequentially and independently, for example, to read the 
-\dotdebugabbrev{} section before the \dotdebuginfo{} section.  
-Each DWARF data section is a sequential sequence of 8-bit bytes, 
+read sequentially and independently.
+\bb\eb
+Each DWARF data section is a \bb\eb sequence of 8-bit bytes, 
 numbered starting with zero.  The presence of offsets from one 
 DWARF data section into other data sections does not imply that 
 the underlying OS must be able to position files randomly; a 
@@ -167,11 +183,7 @@ data section could be read sequentially and indexed using the offset.
 
 \subsection{Compact Data Representation} 
 The DWARF description is designed to be a compact file-oriented 
-representation. In most cases, it is anticipated that DWARF 
-debug data will be read by a consumer (usually a debugger) and 
-onverted into a more efficiently accessed internal representation.  
-For the most part, the DWARF data in a section is not the same as 
-this internal representation. 
+representation.\bb\eb
 
 There are several encodings which achieve this goal, such as the 
 TAG and attribute abbreviations or the line number encoding.  
@@ -187,9 +199,13 @@ which allow a consumer to find DWARF data in files other than
 the executable, or the type units, which allow similar type 
 definitions from multiple compilations to be combined. 
 
-There is a tension between this objective and the following 
-objective. Every compaction scheme results in more processing 
-which needs to be performed to process the DWARF debug data. 
+\bb
+In most cases, it is anticipated that DWARF 
+debug data will be read by a consumer (usually a debugger) and 
+converted into a more efficiently accessed internal representation.  
+For the most part, the DWARF data in a section is not the same as 
+this internal representation.
+\eb
 
 \subsection{Efficient Processing} 
 DWARF is designed to be processed efficiently, so that a 
@@ -208,9 +224,14 @@ the possible implementations.
 DWARF attempts to allow developers the greatest flexibility 
 in designing implementations, without mandating any particular 
 design decisions. Issues which can be described as 
-\doublequote{Quality of Implementation} are avoided.
+\bb
+quality-of-implementation
+\eb
+are avoided.
 
-\subsection{Explicit rather than Implicit Description}
+\bb
+\subsection{Explicit Rather Than Implicit Description}
+\eb
 DWARF describes the source to object translation explicitly 
 rather than using common practice or convention as an implicit 
 understanding between producer and consumer.  For example, where 
@@ -224,15 +245,25 @@ DWARF has a goal of describing characteristics of a program once,
 rather than repeating the same information multiple times.  The 
 string sections can be compacted to eliminate duplicate strings, 
 for example.  Other compaction schemes or references between 
-ections support this. Whether a particular implementation is 
+\bb
+sections 
+\eb
+support this. Whether a particular implementation is 
 effective at eliminating duplicate data, or even attempts to, 
-is a Quality of Implementation issue.  
+is a 
+\bb
+quality-of-implementation
+\eb
+issue.  
 
 \subsection{Leverage Other Standards}
 Where another standard exists which describes how to interpret 
 aspects of a program, DWARF defers to that standard rather than 
 attempting to duplicate the description.  For example, C++ has 
-pecific rules for deciding which function to call depending 
+\bb
+specific 
+\eb
+rules for deciding which function to call depending 
 name, scope, argument types, and other factors.  DWARF describes 
 the functions and arguments, but doesn't attempt to describe 
 how one would be selected by a consumer performing any particular 
@@ -245,13 +276,20 @@ without requiring additional functionality specifically to
 support DWARF data.  This may require the implementer to be 
 careful that they do not generate DWARF data which cannot be 
 processed by these programs.  Conversely, an assembler which 
-can generate LEB128 values may allow the compiler to generate 
+can generate LEB128 
+\bb
+(Little-Endian Base 128) 
+\eb
+values may allow the compiler to generate 
 more compact descriptions, and a linker which understands the 
 format of string sections can merge these sections.  Whether 
-or not an implementation includes these functions is a Quality 
-of Implementation issue, not mandated by the DWARF specification.
+or not an implementation includes these functions is a 
+\bb
+quality-of-implementation 
+\eb
+issue, not mandated by the DWARF specification.
 
-\subsection{Separate Description from Implementation}
+\subsection{Separate Description From Implementation}
 DWARF intends to describe the translation of a program from 
 source to object, while neither mandating any particular design 
 nor making any other design difficult.  For example, DWARF 
@@ -259,9 +297,15 @@ describes how the arguments and local variables in a function
 are to be described, but doesn't specify how this data is 
 collected or organized by a producer.  Where a particular DWARF 
 feature anticipates that it will be implemented in a certain 
-fashion, non-normative text will suggest but not require this design.
+fashion, 
+\bb
+informative 
+\eb
+text will suggest but not require this design.
 
-\subsection{Permissive rather than Prescriptive}
+\bb 
+\subsection{Permissive Rather Than Prescriptive}
+\eb
 The DWARF Standard specifies the meaning of DWARF descriptions.  
 It does not specify what a particular producer should generate 
 for any source to object conversion, nor what a particular 
@@ -270,13 +314,16 @@ allowing different producer to generate different descriptions
 for the same source to object conversion.  As long as the DWARF 
 description follows this specification, the producer is 
 generating valid DWARF.
-For example, DWARF allows producers to identify the end of a 
+For example, DWARF allows 
+\bb
+a producer 
+\eb
+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.  
 
 \subsection{Vendor Extensibility}
-\eb
 This document does not attempt to cover all interesting
 languages or even to cover all of the possible debugging
 information needs for its primary target languages. 
@@ -296,9 +343,7 @@ All
 names and values not reserved for vendor additions, however,
 are reserved for future versions of this document.
 
-\bb
 Where this specification provides a means for
-\eb
 describing the source language, implementors are expected
 to adhere to that specification. 
 For language features that
@@ -316,7 +361,9 @@ to read and process files generated according to a later
 version of this standard or which contain vendor extensions,
 albeit possibly in a degraded manner.
 
-\section{Changes from Version 4 to Version 5}
+\bb
+\section{Changes From Version 4 to Version 5}
+\eb
 \addtoindexx{DWARF Version 5}
 The following is a list of the major changes made to the DWARF Debugging Information
 Format since Version 4 was published. The list is not meant to be exhaustive.
@@ -324,13 +371,25 @@ Format since Version 4 was published. The list is not meant to be exhaustive.
 \item The \dotdebugtypes{}
 %\addtoindexi{\texttt{.debug\_types}}{\texttt{.debug\_types} (Version 4)}
 section introduced in \DWARFVersionIV{} 
-is eliminated and its contents instead contained in \dotdebuginfo{} sections
-to facilitate other changes.
-\item Add support for collecting common DWARF information (DIEs and macro definitions)
+is eliminated and its contents instead contained in \dotdebuginfo{} sections.
+\bb\eb
+\item Add support for collecting common DWARF information 
+\bb
+(debugging information entries 
+\eb
+and macro definitions)
 across multiple executable and shared files and keeping it in a single
 \addtoindex{supplementary object file}.
-\item A new line number program header design provides the ability to 
-use an MD5 hash to validate source file version in use, allows pooling 
+\item A new line number program header 
+\bb
+format 
+\eb
+provides the ability to 
+use an MD5 hash to validate 
+\bb
+the
+\eb
+source file version in use, allows pooling 
 of directory and file name strings and makes provision for vendor-defined
 extensions. It also adds a string section specific to the line number table 
 (\dotdebuglinestr)
@@ -338,35 +397,55 @@ to properly support the common practice of stripping all DWARF sections
 except for line number information.
 \needlines{4}
 \item Add a split object file and package representations to allow most 
-DWARF information to be compacted and/or kept separate from an executable 
+DWARF information to be 
+\bb\eb
+kept separate from an executable 
 or shared image. This includes new sections 
 \dotdebugaddr, \dotdebugstroffsets, \dotdebugabbrevdwo, \dotdebuginfodwo, 
 \dotdebuglinedwo, \dotdebuglocdwo, \dotdebugmacrodwo, \dotdebugstrdwo,
 \dotdebugstroffsetsdwo, \dotdebugcuindex{} and \dotdebugtuindex{} 
 together with new forms of attribute value for referencing these sections.
-This enhances DWARF support for very large programs by saving space 
-and improving link times.
+This enhances DWARF support 
+\bb
+by reducing executable program size and
+by improving link times.
+\eb
 \item Replace the \dotdebugmacinfo{} macro information representation with
-a much more compact \dotdebugmacro{} representation.
+\bb
+with a \dotdebugmacro{} representation that can potentially be much more compact.
+\eb
 \item Replace the \dotdebugpubnames{} and \dotdebugpubtypes{} sections
 with a single and more functional name index section, \dotdebugnames{}.
-\item Add a new debugging information entry (\DWTAGcallsiteNAME) and related 
+\item Add a new debugging information entry (\DWTAGcallsiteNAME), related 
+\bb\eb
 attributes and DWARF expression operators to describe call site information, 
 including identification of tail calls and tail recursion.
-This facilitates debugging of optimized code.
+\bb\eb
 \item Add improved support for \addtoindex{FORTRAN} assumed rank arrays 
 (\DWTAGgenericsubrangeNAME), dynamic rank arrays (\DWATrankNAME)
 and co-arrays (\DWTAGcoarraytypeNAME{}).
-\item Add a new option to allow debuggers and other DWARF consumers to
-support a DWARF expression stack containing typed values.
-\item Add improved support for the \addtoindex{C++} \texttt{auto}
-return type, deleted member functions (\DWATdeletedNAME), as well as defaulted 
-constructors and destructors (\DWATdefaultedNAME).
-\item Add a new attribute, \DWATnoreturnNAME{}, to identify 
+\item Add
+\bb
+new operations that allow support for 
+\eb
+a DWARF expression stack containing typed values.
+\item Add improved support for the \addtoindex{C++}:
+\bb\eb
+\texttt{auto} return type, deleted member functions (\DWATdeletedNAME), 
+as well as defaulted constructors and destructors (\DWATdefaultedNAME).
+\item Add a new attribute 
+\bb
+(\DWATnoreturnNAME{}), 
+\eb
+to identify 
 a subprogram that does not return to its caller.
 \item Add language codes for C 2011, C++ 2003, C++ 2011, C++ 2014,
 Dylan, Fortran 2003, Fortran 2008, Go, Haskell, 
-Julia, Modula 3, Ocaml, Rust, OpenCL and Swift.
+Julia, Modula 3, Ocaml, 
+\bb
+OpenCL, Rust 
+\eb
+and Swift.
 \item Numerous other more minor additions to improve functionality
 and performance.
 \end{itemize}
@@ -377,22 +456,35 @@ DWARF Version 5 is compatible with DWARF Version 4 except as follows:
 a new \HFNunittype{} field.
 \needlines{4}
 \item New operand forms for attribute values are defined 
-(\DWFORMaddrxNAME, \DWFORMdatasixteenNAME, \DWFORMlinestrpNAME, 
+(\DWFORMaddrxNAME, \DWFORMdatasixteenNAME, 
+\bb
+\DWFORMimplicitconstNAME, 
+\eb
+\DWFORMlinestrpNAME, 
 \DWFORMrefsupNAME, \DWFORMstrpsupNAME{} and \DWFORMstrxNAME).
-(Because a pre-DWARF Version 5 consumer will not be able to interpret 
-these even to ignore and skip over them, such new forms must be 
-considered incompatible.)
-\item The line number table header (in the \dotdebugline{} section) 
+
+\textit{Because a pre-DWARF Version 5 consumer will not be able to interpret 
+these even to ignore and skip over them, new forms must be 
+considered incompatible additions.}
+\item The line number table header 
+\bb\eb 
 is substantially revised.
 \needlines{4}
-\item A location list entry (see Section \refersec{chap:locationlists}) 
+\item A location list entry 
+\bb\eb
 with the address range \mbox{(0, \textit{maximum-address})} is defined 
 as the new default location list entry.
-\item In a string type (see Section \refersec{chap:stringtypeentries}), 
-a \DWATbytesizeNAME{} attribute is defined to always describe the size 
-of the string type. (Previously
-it described the size of the optional string length data field if the 
-\DWATstringlengthNAME{} attribute was present.)
+\item In a string type,
+\bb 
+the \DWATbytesizeNAME{} attribute is re-defined 
+\eb
+to always describe the size of the string type. 
+(Previously it described the size of the optional string length data 
+field if the \DWATstringlengthNAME{} attribute was 
+\bb
+also 
+\eb
+present.)
 \end{itemize}
 
 While not strictly an incompatibility, the macro information 
index 9f269f5..86e9c86 100644 (file)
@@ -91,7 +91,6 @@ declaration in the \dotdebuginfo{} section.
 The name index may also contain an optional hash table for faster
 lookup.
 
-\bb
 A relocatable object file may contain a "per-CU" index, which
 provides an index to the names defined in that compilation
 unit.
@@ -101,7 +100,6 @@ An executable or shareable object file may contain either a collection of
 file, or the linker may produce a "per-module" index by
 combining the per-CU indexes into a single index that covers
 the entire load module.
-\eb
 
 \subsubsection{Contents of the Name Index}
 \label{chap:contentsofthenameindex}
@@ -183,7 +181,6 @@ Figure \referfol{fig:nameindexlayoutpart1}.
 \end{enumerate}
 
 \begin{figure}[p]
-\bb
 \figurepart{1}{2}
 \begin{center}
 %\includegraphics[keepaspectratio=true,scale=1.0]{name-index-drawings-6p1}
@@ -332,11 +329,9 @@ Figure \referfol{fig:nameindexlayoutpart1}.
 \caption{Name Index Layout}
 \label{fig:nameindexlayoutpart1}
 \end{center}
-\eb
 \end{figure}
 
 \begin{figure}[p]
-\bb
 \figurepart{2}{2}
 \begin{center}
 %\includegraphics[keepaspectratio=true,scale=1.0]{name-index-drawings-6p2}
@@ -502,7 +497,6 @@ Figure \referfol{fig:nameindexlayoutpart1}.
 Figure~\ref{fig:nameindexlayoutpart1}: Name Index Layout \textit{(concluded)}
 %\label{fig:nameindexlayoutpart2}
 \end{center}
-\eb
 \end{figure}
 
 The formats of the header and the hash lookup table are described
@@ -585,21 +579,17 @@ attributes for both CU and (foreign) TU. For such entries, the CU
 attribute gives the consumer a reference to the CU that may be used to
 locate a \splitDWARFobjectfile{} that contains the type unit.
 
-\bb
 \textit{The type hash attribute, not to be confused with the type signature
 for a TU, may be provided for type entries whose declarations are not
 in a type unit, for the convenience of link-time or post-link
 utilities that wish to de-duplicate type declarations across
 compilation units. The type hash, however, is computed by the
 same method as specified for type signatures.}
-\eb
 
 The last entry for each name is followed by a zero byte that
 terminates the list. There may be gaps between the lists.
 
-\bb
 \subsubsection{Per-CU versus Per-Module Indexes}
-\eb
 \label{chap:percuvspermoduleindexes}
 \textit{In a per-CU index, the CU list may have only a single entry, 
 and index entries may omit the CU attribute. (Cross-module or link-time
@@ -753,11 +743,7 @@ hashes array is indexed starting at 1, and an empty bucket is
 represented by the value 0.
 
 \needlines{4}
-The hashes array contains a 
-\bb
-sequence
-\eb
-of the full hash values for each
+The hashes array contains a sequence of the full hash values for each
 symbol. All symbols that have the same index into the bucket list 
 follow one another in the hashes array, and the indexed entry in 
 the bucket list refers to the first symbol. 
index cfd8b0f..d8c7b34 100644 (file)
@@ -4,8 +4,8 @@ This section describes debugging information entries that
 relate to different levels of program scope: compilation,
 module, subprogram, and so on. Except for separate type
 entries (see Section \refersec{chap:typeunitentries}), 
-these entries may be thought of
-as bounded by ranges of text addresses within the program.
+these entries may be thought of as
+\bb\eb ranges of text addresses within the program.
 
 \section{Unit Entries}
 \label{chap:unitentries}
@@ -21,10 +21,7 @@ related partial compilation units and/or type units.
 
 \item A \definition{partial compilation unit} describes
 a part of a compilation (generally corresponding to an
-\bb
-imported module) 
-\eb
-which is imported into one or more 
+imported module) which is imported into one or more 
 related full compilation units.
 
 \item A \definition{type unit} is a specialized unit
@@ -63,9 +60,7 @@ is part of the same object file as the compiled code and data.}
 
 \begin{itemize}
 \item A 
-\bb
 \definition{split compilation unit} describes
-\eb
 a complete compilation, possibly in combination with
 related type compilation units. It corresponds 
 to a specific skeleton compilation unit.
@@ -78,7 +73,11 @@ be usefully shared by multiple other units.
 
 \textit{Split compilation units and split type units may be 
 contained in object files separate from those containing the 
-program code and data.}
+program code and data.
+\bb
+These object files are not processed by a linker; thus,
+split units do not depend on underlying object file relocations.
+\eb}
 
 \textit{Either a full compilation unit or a partial compilation 
 unit may be logically incorporated into another compilation unit 
@@ -86,9 +85,7 @@ using an \addtoindex{imported unit entry}
 (see Section \refersec{chap:importedunitentries}).}
 
 \textit{A
-\bb
 combined split and partial
-\eb
 compilation unit kind is not defined.}
 
 \textit{In the remainder of this document, the word 
@@ -492,9 +489,7 @@ compilation unit.
 \livetarg{chap:DWATdwoidforunit}{}
 A \DWATdwoidDEFN{} attribute\addtoindexx{unit identification attribute}
 whose implementation-defined integer constant value,
-\bb
 known as the \CUsignature,
-\eb
 provides unique identification of this compilation unit
 as well as the associated split compilation unit in the
 object file named in the \DWATdwoname{}
@@ -504,11 +499,9 @@ split full compilation unit
 (see Section \refersec{chap:splitfullcompilationunitentries})
 must use the same form to encode this identification value.
 
-\bb
 \textit{The means of determining a \CUsignature{} does not 
 need to be similar or related to the means of determining a
 \TUsignature.}
-\eb 
 
 \end{enumerate}
 
@@ -589,9 +582,7 @@ A split full compilation unit has a \DWATdwoid{} attribute:
 \item
 A \DWATdwoidDEFN{} attribute\addtoindexx{unit identification attribute}
 whose implementation-defined integer constant value,
-\bb
 known as the \CUsignature,
-\eb
 provides unique identification of this compilation unit
 as well as the associated skeleton compilation unit.
 For simplicity, the \DWATdwoidNAME{} attributes in the 
@@ -599,11 +590,9 @@ split compilation unit and the associated skeleton
 compilation unit must use the same form to encode the 
 identification value.
 
-\bb
 \textit{The means of determining a \CUsignature{} does not 
 need to be similar or related to the means of determining a
 \TUsignature.}
-\eb 
 
 \end{enumerate}
 
@@ -919,7 +908,7 @@ attribute in any namespace extension entry of this namespace).
 \textit{A compiler emitting namespace information may choose to
 explicitly represent namespace extensions, or to represent the
 final namespace declaration of a compilation unit; this is a
-quality\dash of\dash implementation issue and no specific requirements
+quality-of-implementation issue and no specific requirements
 are given here. If only the final namespace is represented,
 \addtoindexx{namespace (C++)!using declaration}
 it is impossible for a debugger to interpret using declaration
index e4763ed..fbdc9ed 100644 (file)
@@ -862,7 +862,6 @@ address range.
 \label{app:dwarfpackagefileexample}
 \addtoindexx{DWARF duplicate elimination!examples}
 
-\bb
 A \definitionx{DWARF package file} is a collection of split 
 DWARF object files.
 In general, it will be much smaller than the sum of the split
@@ -912,10 +911,8 @@ combining \texttt{demo1.dwo} and \texttt{demo2.dwo} from the previous example
 resulting package file would contain the sections shown in Figure
 \refersec{fig:sectionsandcontributionsinapackagefile}, 
 with contributions from each input file as shown.
-\eb
 
 \begin{figure}[h]
-\bb
 \begin{center}
 \begin{tabular}{P{4.7cm}|P{8cm}}
 \hline
@@ -957,11 +954,9 @@ with contributions from each input file as shown.
 \end{center}
 \caption{Sections and contributions in a package file}
 \label{fig:sectionsandcontributionsinapackagefile}
-\eb
 \end{figure}
 
 \needlines{4}
-\bb
 The \dotdebugabbrevdwo{}, \dotdebuglocdwo{} and \dotdebuglinedwo{}
 sections have been copied over from the two \texttt{.dwo} files as
 individual contributions to the corresponding sections in the
@@ -1007,10 +1002,8 @@ to \dotdebuglocdwo{} begins at offset 84, so the location list from
 Figure \refersec{fig:splitobjectexampledemotwodwodwarfdebuglocdwoexcerpts} 
 can be found in \texttt{demo.dwp} at offset 157 (84 + 73) in
 the combined \dotdebuglocdwo{} section.
-\eb
 
 \begin{figure}[h]
-\bb
 \begin{center}
 \begin{tabular}{lrrrrrr}
 \hline \\
@@ -1035,11 +1028,9 @@ the combined \dotdebuglocdwo{} section.
 \end{center}
 \caption{Example CU index section}
 \label{fig:examplecuindexsection}
-\eb
 \end{figure}
 
 \needlines{4}
-\bb
 Figure \referfol{fig:exampletuindexsection} 
 shows an example TU index section containing the
 three type units for classes \texttt{Box}, \texttt{Point}, and 
@@ -1055,10 +1046,8 @@ from \texttt{demo2.dwo}. (The
 sharing of these tables between compilation units and type units
 is typical for some implementations, but is not required by the
 DWARF standard.)
-\eb
 
 \begin{figure}[h]
-\bb
 \begin{center}
 \begin{tabular}{lrrrrr}
 \hline
@@ -1077,15 +1066,14 @@ DWARF standard.)
   \multicolumn{6}{c}{Size table} \\
   \hline
   slot&                          &     info&   abbrev&     line& str\_off \\
-  11&                            &     167&      452&       52&       72 \\
-  17&                            &     217&      593&       52&      120 \\
-  27&                            &     323&      452&       52&       72 \\
+  11&                            &      167&      452&       52&       72 \\
+  17&                            &      217&      593&       52&      120 \\
+  27&                            &      323&      452&       52&       72 \\
 \\
 \hline
 \end{tabular}
 \end{center}
 \caption{Example TU index section}
 \label{fig:exampletuindexsection}
-\eb
 \end{figure}
 
index a49b12f..52cb8af 100644 (file)
@@ -843,11 +843,7 @@ a separate \addtoindex{type unit}
 an incomplete declaration 
 \addtoindexx{incomplete type}
 of that type in the compilation unit may provide
-the unique 
-\bb
-8-byte 
-\eb
-signature of the type using a
+the unique 8-byte signature of the type using a
 \addtoindexx{type signature}
 \DWATsignatureDEFN{} attribute.