This corresponds to the August 11, 2015 distribution...
authorRon Brender <ron.brender@gmail.com>
Tue, 11 Aug 2015 13:27:15 +0000 (09:27 -0400)
committerRon Brender <ron.brender@gmail.com>
Tue, 11 Aug 2015 13:27:15 +0000 (09:27 -0400)
Signed-off-by: Ron Brender <ron.brender@gmail.com>
dwarf5/latexdoc/changesummary.tex
dwarf5/latexdoc/datarepresentation.tex
dwarf5/latexdoc/dwarf5.tex
dwarf5/latexdoc/generaldescription.tex
dwarf5/latexdoc/introduction.tex
dwarf5/latexdoc/otherdebugginginformation.tex
dwarf5/latexdoc/selectedglossary.tex [new file with mode: 0644]
dwarf5/latexdoc/typeentries.tex

index c88412a..18ab093 100644 (file)
@@ -15,7 +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
 \begin{longtable}{ll}
 \textbf{Date}  & \textbf{Issue Incorporated or Other Change}   \\ \hline       \\
 \endhead
-7/28-8/6/2015   & 150623.1 (MD5 digest), new F.3 (.dwp files), remove trial Selected Glossary, \\
+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), \\
                 & add trial Selected Glossary appendix, more editorial work IX \\
                 & 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), \\
                 & add trial Selected Glossary appendix, more editorial work IX \\
index 95891e9..bf02b2b 100644 (file)
@@ -2376,7 +2376,7 @@ offsets are the same size as an address on the target machine.
 For a \addtoindex{location list} to be specified, the base address of
 \addtoindexx{base address selection entry!in location list}
 the corresponding compilation unit must be defined 
 For a \addtoindex{location list} to be specified, the base address of
 \addtoindexx{base address selection entry!in location list}
 the corresponding compilation unit must be defined 
-(see Section \refersec{chap:normalandpartialcompilationunitentries}).
+(see Section \refersec{chap:fullandpartialcompilationunitentries}).
 
 \subsubsection{Location List Entries in Split Objects}
 \label{datarep:locationlistentriesinsplitobjects}
 
 \subsubsection{Location List Entries in Split Objects}
 \label{datarep:locationlistentriesinsplitobjects}
@@ -3213,7 +3213,7 @@ addresses are the same size as addresses on the target machine.
 For a \addtoindex{range list} to be specified, the base address of the
 \addtoindexx{base address selection entry!in range list}
 corresponding compilation unit must be defined 
 For a \addtoindex{range list} to be specified, the base address of the
 \addtoindexx{base address selection entry!in range list}
 corresponding compilation unit must be defined 
-(see Section \refersec{chap:normalandpartialcompilationunitentries}).
+(see Section \refersec{chap:fullandpartialcompilationunitentries}).
 
 \needlines{6}
 \section{String Offsets Table}
 
 \needlines{6}
 \section{String Offsets Table}
index 196c09e..987b87d 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.
 %
 % 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 6, 2015}
+\newcommand{\docdate}{August 11, 2015}
 %
 \usepackage{ifthen}
 \newcommand{\ifthen}[2]{\ifthenelse{#1}{#2}{}}
 %
 \usepackage{ifthen}
 \newcommand{\ifthen}[2]{\ifthenelse{#1}{#2}{}}
index e7d0495..270481d 100644 (file)
@@ -520,16 +520,16 @@ The attributes are listed in Table \referfol{tab:attributenames}.
 \DWATimportTARG
 &\livelinki{chap:DWATimportimporteddeclaration}
         {Imported declaration}
 \DWATimportTARG
 &\livelinki{chap:DWATimportimporteddeclaration}
         {Imported declaration}
-        {imported declaration} \\
+        {imported declaration} \\*
 &\livelinki{chap:DWATimportimportedunit}
         {Imported unit}
 &\livelinki{chap:DWATimportimportedunit}
         {Imported unit}
-        {imported unit} \\
+        {imported unit} \\*
 &\livelinki{chap:DWATimportnamespacealias}
         {Namespace alias}
 &\livelinki{chap:DWATimportnamespacealias}
         {Namespace alias}
-        {namespace alias} \\
+        {namespace alias} \\*
 &\livelinki{chap:DWATimportnamespaceusingdeclaration}
         {Namespace using declaration}
 &\livelinki{chap:DWATimportnamespaceusingdeclaration}
         {Namespace using declaration}
-        {namespace using declaration} \\
+        {namespace using declaration} \\*
 &\livelinki{chap:DWATimportnamespaceusingdirective}
         {Namespace using directive}
         {namespace using directive} \\
 &\livelinki{chap:DWATimportnamespaceusingdirective}
         {Namespace using directive}
         {namespace using directive} \\
@@ -2246,7 +2246,7 @@ determined by the closest preceding base address selection
 entry (\DWLLEbaseaddressselectionentry) in the same location list. If there is
 no such selection entry, then the applicable base address
 defaults to the base address of the compilation unit (see
 entry (\DWLLEbaseaddressselectionentry) in the same location list. If there is
 no such selection entry, then the applicable base address
 defaults to the base address of the compilation unit (see
-Section \refersec{chap:normalandpartialcompilationunitentries}).
+Section \refersec{chap:fullandpartialcompilationunitentries}).
 
 Each entry in the split location list
 begins with a type code, which is a single unsigned byte that
 
 Each entry in the split location list
 begins with a type code, which is a single unsigned byte that
@@ -2305,6 +2305,7 @@ range for which this location is valid. A single location
 description follows the fields that define the address range.
 \end{enumerate}
 
 description follows the fields that define the address range.
 \end{enumerate}
 
+\needlines{4}
 \textit{The \DWLLEbaseaddressselectionentry, \DWLLEstartendentry{}
 and \DWLLEstartlengthentry entries obtain addresses within the 
 target program indirectly using an index (not an offset) into an 
 \textit{The \DWLLEbaseaddressselectionentry, \DWLLEstartendentry{}
 and \DWLLEstartlengthentry entries obtain addresses within the 
 target program indirectly using an index (not an offset) into an 
@@ -2854,7 +2855,7 @@ by the closest preceding base address selection entry (see
 below) in the same range list. If there is no such selection
 entry, then the applicable base address defaults to the base
 address of the compilation unit 
 below) in the same range list. If there is no such selection
 entry, then the applicable base address defaults to the base
 address of the compilation unit 
-(see Section \refersec{chap:normalandpartialcompilationunitentries}).
+(see Section \refersec{chap:fullandpartialcompilationunitentries}).
 
 \textit{In the case of a compilation unit where all of the machine
 code is contained in a single contiguous section, no base
 
 \textit{In the case of a compilation unit where all of the machine
 code is contained in a single contiguous section, no base
index de84adb..aa6eeee 100644 (file)
@@ -91,66 +91,189 @@ of the formal definition.
 \bb
 \section{Objectives and Rationale}
 
 \bb
 \section{Objectives and Rationale}
 
-DWARF has had a set of objectives since its inception which have guided the design and evolution of the debugging format.  A discussion of these objectives and the rationale behind them may help with an 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, DWARF Version 2 and later has evolved far beyond this origin. One difference between DWARF and other object formats is that the latter are often specific to a particular language, architecture, and/or operating system. 
+DWARF has had a set of objectives since its inception which have 
+guided the design and evolution of the debugging format.  A discussion 
+of these objectives and the rationale behind them may help with an 
+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 
+is that the latter are often specific to a particular language, 
+architecture, and/or operating system. 
 
 \subsection{Language Independence}
 
 \subsection{Language Independence}
-DWARF is applicable to a broad range of existing procedural languages and is designed to be extensible to future languages.  These languages may be considered to be "C-like" but the characteristics of C are not incorporated into DWARF Version 2 and later, unlike DWARF Version 1 and other debugging formats.  DWARF abstracts concepts as much as possible so that the description can be used to describe a program in any language. As an example, the DWARF descriptions used to describe C functions, Pascal subroutines, and Fortran subprograms are all the same, with different attributes used to specify the differences between these similar programming language features. 
-
-On occasion, there is a feature which is specific to one 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 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 which had similar functionality. 
+DWARF is applicable to a broad range of existing procedural 
+languages and is designed to be extensible to future languages.  
+These languages may be considered to be "C-like" but the 
+characteristics of C are not incorporated into DWARF Version 2 
+and later, unlike DWARF Version 1 and other debugging formats.  
+DWARF abstracts concepts as much as possible so that the 
+description can be used to describe a program in any language. 
+As an example, the DWARF descriptions used to describe C functions, 
+Pascal subroutines, and Fortran subprograms are all the same, 
+with different attributes used to specify the differences between 
+these similar programming language features. 
+
+On occasion, there is a feature which is specific to one 
+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 
+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 
+which had similar functionality. 
 
 \subsection{Architecture Independence}
 
 \subsection{Architecture Independence}
-DWARF can be used with a wide range of processor architectures, whether byte or word oriented, linear or segmented, with any word or byte size.  DWARF can be used with Von Neumann architectures, using a single address space for both code and data; Harvard architectures, with 
-separate code and data address spaces; and potentially for other architectures such as DSPs with their idiosyncratic memory organizations.  DWARF can be used with common register-oriented architectures or with stack architectures. 
-
-DWARF assumes that memory has individual units (words or bytes) which have unique addresses which are ordered.  (Some architectures like the i386 can represent the same physical machine location with different segment/offset pairs.  Identifying aliases is an implementation issue.)
+DWARF can be used with a wide range of processor architectures, 
+whether byte or word oriented, linear or segmented, with any 
+word or byte size.  DWARF can be used with Von Neumann architectures, 
+using a single address space for both code and data; Harvard 
+architectures, with separate code and data address spaces; and 
+potentially for other architectures such as DSPs with their 
+idiosyncratic memory organizations.  DWARF can be used with 
+common register-oriented architectures or with stack architectures. 
+
+DWARF assumes that memory has individual units (words or bytes) 
+which have unique addresses which are ordered.  (Some architectures 
+like the i386 can represent the same physical machine location with 
+different segment and offset pairs.  Identifying aliases is an 
+implementation issue.)
 
 \subsection{Operating System Independence}
 
 \subsection{Operating System Independence}
-DWARF is widely associated with SVR4 Unix and similar operating 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. 
-
-DWARF assumes that any object file format will be able to distinguish the various DWARF data sections in some fashion, 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, 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 data section could be read sequentially and indexed using the offset. 
+DWARF is widely associated with SVR4 Unix and similar operating 
+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. 
+
+DWARF assumes that any object file format will be able to 
+distinguish the various DWARF data sections in some fashion, 
+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, 
+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 
+data section could be read sequentially and indexed using the offset. 
 
 \subsection{Compact Data Representation} 
 
 \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 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. 
-
-There are several encodings which achieve this goal, such as the TAG and attribute abbreviations or the line number encoding.  References from one section to another, especially to refer to strings, allow these sections to be compacted to eliminate duplicate data. 
-
-There are multiple schemes for eliminating duplicate data or reducing the size of the DWARF debug data associated with a given file.  These include COMDAT, used to eliminate duplicate function or data definitions, the split DWARF object files 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. 
+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. 
+
+There are several encodings which achieve this goal, such as the 
+TAG and attribute abbreviations or the line number encoding.  
+References from one section to another, especially to refer to 
+strings, allow these sections to be compacted to eliminate 
+duplicate data. 
+
+There are multiple schemes for eliminating duplicate data or 
+reducing the size of the DWARF debug data associated with a 
+given file.  These include COMDAT, used to eliminate duplicate 
+function or data definitions, the split DWARF object files 
+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. 
 
 \subsection{Efficient Processing} 
 
 \subsection{Efficient Processing} 
-DWARF is designed to be processed efficiently, so that a producer (a compiler) can generate the debug descriptions incrementally and a consumer can read only the descriptions which it needs at a given time. The data formats are designed to be efficiently interpreted by a consumer.
-
-As mentioned, there is a tension between this objective and the preceding one.  A DWARF data representation which resembles an internal data representation may lead to faster processing, but at the expense of larger data files. This may also constrain the possible implementations.
+DWARF is designed to be processed efficiently, so that a 
+producer (a compiler) can generate the debug descriptions 
+incrementally and a consumer can read only the descriptions 
+which it needs at a given time. The data formats are designed 
+to be efficiently interpreted by a consumer.
+
+As mentioned, there is a tension between this objective and 
+the preceding one.  A DWARF data representation which resembles 
+an internal data representation may lead to faster processing, 
+but at the expense of larger data files. This may also constrain 
+the possible implementations.
 
 \subsection{Implementation Independence}
 
 \subsection{Implementation Independence}
-DWARF attempts to allow developers the greatest flexibility in designing implementations, without mandating any particular design decisions.  We avoid issues which can be described as “Quality of Implementation”, where the decisions made by an implementer may affect performance or functionality.  
+DWARF attempts to allow developers the greatest flexibility 
+in designing implementations, without mandating any particular 
+design decisions. Issues which can be described as “Quality of 
+Implementation” are avoided.
 
 \subsection{Explicit rather than Implicit Description}
 
 \subsection{Explicit rather than Implicit Description}
-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 other debugging formats assume that a debugger knows how to unwind the stack, moving from one stack frame to the next using implicit knowledge about the architecture or operating system, DWARF makes this explicit in the Call Frame Information description.
+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 
+other debugging formats assume that a debugger knows how to 
+unwind the stack, moving from one stack frame to the next using 
+implicit knowledge about the architecture or operating system, 
+DWARF makes this explicit in the Call Frame Information description.
 
 \subsection{Avoid Duplication of Information}
 
 \subsection{Avoid Duplication of Information}
-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 sections support this.
-Whether a particular implementation is effective at eliminating duplicate data, or even attempts to, is a Quality of Implementation issue.  
+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 
+effective at eliminating duplicate data, or even attempts to, 
+is a Quality of Implementation issue.  
 
 \subsection{Leverage Other Standards}
 
 \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 specific 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 operation.
+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 
+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 
+operation.
 
 \subsection{Limited Dependence on Tools}
 
 \subsection{Limited Dependence on Tools}
-DWARF data is designed so that it can be processed by commonly available assemblers, linkers, and other support programs, 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 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.
+DWARF data is designed so that it can be processed by commonly 
+available assemblers, linkers, and other support programs, 
+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 
+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.
 
 \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 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.
+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 
+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.
 
 \subsection{Permissive rather than Prescriptive}
 
 \subsection{Permissive rather than Prescriptive}
-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 consumer should do with this description.  DWARF is permissive, 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 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.  
+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 
+consumer should do with this description.  DWARF is permissive, 
+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 
+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
 
 \subsection{Vendor Extensibility}
 \eb
index 39b5cd1..9f269f5 100644 (file)
@@ -157,7 +157,7 @@ another has a struct named \texttt{fred}, a lookup for \doublequote{fred} will f
 list containing those two index entries.
 
 The index section contains eight individual parts, as illustrated in 
 list containing those two index entries.
 
 The index section contains eight individual parts, as illustrated in 
-Figure \referfol{fig:nameindexlayout}.
+Figure \referfol{fig:nameindexlayoutpart1}.
 \begin{enumerate}
 \item A header, describing the layout of the section.
 
 \begin{enumerate}
 \item A header, describing the layout of the section.
 
@@ -954,7 +954,7 @@ represented in the
 also in the \dotdebuglinestr{} section, and
 is referenced by a corresponding compilation unit debugging
 information entry 
 also in the \dotdebuglinestr{} section, and
 is referenced by a corresponding compilation unit debugging
 information entry 
-(see Section \refersec{chap:normalandpartialcompilationunitentries}) 
+(see Section \refersec{chap:fullandpartialcompilationunitentries}) 
 in the \dotdebuginfo{} section.
 
 \textit{Some computer architectures employ more than one instruction
 in the \dotdebuginfo{} section.
 
 \textit{Some computer architectures employ more than one instruction
@@ -1918,7 +1918,7 @@ programmer wrote it. The macro information table provides a way
 of preserving the original source in the debugging information.}
 
 As described in 
 of preserving the original source in the debugging information.}
 
 As described in 
-Section \refersec{chap:normalandpartialcompilationunitentries},
+Section \refersec{chap:fullandpartialcompilationunitentries},
 the macro information for a
 given compilation unit is represented in the 
 \dotdebugmacro{}
 the macro information for a
 given compilation unit is represented in the 
 \dotdebugmacro{}
diff --git a/dwarf5/latexdoc/selectedglossary.tex b/dwarf5/latexdoc/selectedglossary.tex
new file mode 100644 (file)
index 0000000..29528c7
--- /dev/null
@@ -0,0 +1,80 @@
+\chapter[Selected Glossary (Informative)]{Selected Glossary$^0$ (Informative)}\r
+\footnotetext[0]{\textcolor{green!30!black}{Note to Reviewers--This new Appendix is\r
+an experiment. Comments regarding whether it should be\r
+retained and expanded are solicited. --Ed.}}\r
+\label{app:selectedglossary}\r
+\r
+This appendix contains descriptions for selected terms\r
+and vocabulary used in this document. The focus is on groups\r
+of related terms that may sound similar and/or have similar \r
+meanings but do need to be distinguished. These descriptions\r
+are informal and cannot be used to contradict or change the\r
+meaning given in the main text. \r
+    \r
+\section{Classification of Object Files}\r
+\r
+\begin{description}\r
+\itembf{DWARF object file}: an object file that includes \r
+DWARF information (includes relocatable, hybrid, split, executable,\r
+shareable and package object files).\r
+\r
+\itembf{relocatable DWARF object file (.o\footnote{These \r
+file extensions are typical of Linux and other Unix-based \r
+operating systems, but other extensions are used in other \r
+environments.} file)}: an object file that includes \r
+relocatable program text (code) and data as well as either\r
+one or more DWARF conventional units, or a skeleton unit.\r
+\r
+\itembf{split DWARF object file (.dwo$^1$ file)}: an object \r
+file that contains no program text (code) or data, but does \r
+contain the split units that are associated with a specific \r
+skeleton unit of a different file.\r
\r
+\itembf{hybrid DWARF object file (.o$^1$ file)}: an object \r
+file that contains relocatable program text (code) and data,\r
+the skeleton unit for that code and data, as well as the \r
+split units that are associated with that skeleton unit.\r
+\r
+\itembf{split/hybrid object file}: an object file that is \r
+either a split DWARF object file (.dwo) or a hybrid DWARF \r
+object file (.o), that is, an object file that contains \r
+one or more split units.\r
+\r
+\itembf{supplementary object file}: an object file (typically\r
+a shareable image object file) that contains macro units and\r
+related string information that can be shared with other\r
+object files.\r
+\end{description}\r
+\r
+\section{Kinds of Units}\r
+\r
+\begin{table}[h]\r
+\caption{Kinds of Units and Their Characteristics}\r
+\label{tab:kindsofunitsandtheir characteristics}\r
+\footnotesize\r
+\begin{tabular}{P{3.6cm}llP{3.3cm}}\r
+\hline\r
+\bfseries\r
+Type of unit &\bfseries Unit Type Code &\bfseries Root DIE TAG &\bfseries Other Key \\\r
+(short name) &                &              &\bfseries Characteristics \\\r
+\hline\r
+conventional full compilation unit \newline(full unit) &\DWUTcompile     &\DWTAGcompileunit&\dotdebuginfo \\\r
+\hline\r
+conventional type unit \newline(type unit)             &\DWUTtype        &\DWTAGtypeunit   &\dotdebuginfo \\\r
+\hline\r
+conventional partial unit (partial unit)       &\DWUTpartial     &\DWTAGpartialunit&\dotdebuginfo \\\r
+\hline\r
+skeleton unit \newline (skeleton unit)                 &\DWUTskeleton    &\DWTAGcompileunit&\dotdebuginfo{}\r
+                                                                                            \DWATdwoname{}\r
+                                                                                            \DWATdwoid \\\r
+\hline\r
+split full compilation unit (split full unit)           &\DWUTsplitcompile&\DWTAGcompileunit&\dotdebuginfodwo{}                                                                                            \DWATdwoid \\\r
+\hline\r
+split type unit                                        &\DWUTsplittype   &\DWTAGtypeunit   &\dotdebuginfodwo \\\r
+\hline\r
+\end{tabular} \r
+\end{table}\r
+\r
+Macro units defined in Section \refersec{chap:macroinformation}\r
+are distinctly different from the above units.\r
+\r
\ No newline at end of file
index 192123e..a49b12f 100644 (file)
@@ -1468,7 +1468,7 @@ the source for the template definition, not to any source
 generated artificially by the compiler.
 \end{enumerate}
 
 generated artificially by the compiler.
 \end{enumerate}
 
-
+\needlines{4}
 \subsection{Variant Entries}
 \label{chap:variantentries}
 
 \subsection{Variant Entries}
 \label{chap:variantentries}