b212850d495a35296aa02572cd2082ce36e48bfa
[dwarf-doc.git] / dwarf5 / latexdoc / introduction.tex
1 \chapter{Introduction}
2 \label{chap:introduction}
3 \pagenumbering{arabic}
4 This document defines a format for describing programs to
5 facilitate user source level debugging. This description
6 can be generated by compilers, assemblers and linkage
7 editors. It can be used by debuggers and other tools. 
8 The debugging information format does not favor the design of any
9 compiler or debugger. 
10 Instead, the goal is to create a method
11 of communicating an accurate picture of the source program
12 to any debugger in a form that is extensible to different
13 languages while retaining compatibility.unittype
14   
15 The design of the
16 debugging information format is open-ended, allowing for
17 the addition of new debugging information to accommodate new
18 languages or debugger capabilities while remaining compatible
19 with other languages or different debuggers.
20
21 \section{Purpose and Scope}
22 The debugging information format described in this document is
23 designed to meet the symbolic, source-level debugging needs of
24 different languages in a unified fashion by requiring language
25 independent debugging information whenever possible.  
26 Aspects
27 of individual languages, such as \addtoindex{C++} virtual functions or
28 \addtoindex{Fortran} common 
29 \nolink{blocks}, are accommodated by creating attributes
30 that are used only for those languages. 
31 This document is
32 believed to cover most debugging information needs of 
33 \addtoindex{Ada},
34 \addtoindex{C}, \addtoindex{C++}, \addtoindex{COBOL}, 
35 and \addtoindex{Fortran}; it also covers the basic needs
36 of various other languages.
37
38 This document describes \DWARFVersionV,
39 the fifth generation
40 of debugging information based on the DWARF format. 
41 \DWARFVersionV{} extends \DWARFVersionIV{}
42 in a compatible manner.
43
44 The intended audience for this document is the developers
45 of both producers and consumers of debugging information,
46 typically compilers, debuggers and other tools that need to
47 interpret a binary program in terms of its original source.
48
49
50 \section{Overview}
51
52 There are two major pieces to the description of the DWARF
53 format in this document. The first piece is the informational
54 content of the debugging entries. The second piece is the
55 way the debugging information is encoded and represented in
56 an object file.
57
58 The informational content is described in Chapters
59 \ref{chap:generaldescription} through
60 \ref{chap:otherdebugginginformation}. Chapter 
61 \ref{chap:generaldescription}
62 describes the overall structure of the information
63 and attributes that are common to many or all of the different
64 debugging information entries. Chapters
65 \ref{chap:programscopeentries}, 
66 \ref{chap:dataobjectandobjectlistentries} and 
67 \ref{chap:typeentries} describe
68 the specific debugging information entries and how they
69 communicate the necessary information about the source program
70 to a debugger. Chapter \ref{chap:otherdebugginginformation} 
71 describes debugging information
72 contained outside of the debugging information entries. The
73 encoding of the DWARF information is presented in Chapter
74 \ref{datarep:datarepresentation}.
75
76 This organization closely follows that used in the 
77 \DWARFVersionIV{} document. Except where needed to incorporate
78 new material or to correct errors, the \DWARFVersionIV{}
79 text is generally reused in this document with little or
80 no modification.
81
82 In the following sections, text in normal font describes
83 required aspects of the DWARF format.  Text in \textit{italics} is
84 explanatory or supplementary material, and not part of the
85 format definition itself. The several appendices consist only
86 of explanatory or supplementary material, and are not part
87 of the formal definition.
88
89 \section{Objectives and Rationale}
90
91 DWARF has had a set of objectives since its inception which have 
92 guided the design and evolution of the debugging format.  A discussion 
93 of these objectives and the rationale behind them may help with an 
94 understanding of the DWARF Debugging Format. 
95
96 Although DWARF Version 1 was developed in the late 1980's as a 
97 format to support debugging C programs written for AT\&T hardware 
98 running SVR4, \DWARFVersionII{} and later has evolved far beyond 
99 this origin. One difference between DWARF and other formats 
100 is that the latter are often specific to a particular language, 
101 architecture, and/or operating system. 
102
103 \subsection{Language Independence}
104 DWARF is applicable to a broad range of existing procedural 
105 languages and is designed to be extensible to future languages.  
106 These languages may be considered to be "C-like" but the 
107 characteristics of C are not incorporated into DWARF Version 2 
108 and later, unlike DWARF Version 1 and other debugging formats.  
109 DWARF abstracts concepts as much as possible so that the 
110 description can be used to describe a program in any language. 
111 As an example, the DWARF descriptions used to describe C functions, 
112 Pascal subroutines, and Fortran subprograms are all the same, 
113 with different attributes used to specify the differences between 
114 these similar programming language features. 
115
116 On occasion, there is a feature which is specific to one 
117 particular language and which doesn't appear to have more 
118 general application.  For these, DWARF has a description 
119 designed to meet the language requirements, although, to the 
120 extent possible, an effort is made to generalize the attribute. 
121 An example of this is the \DWTAGconditionNAME{} 
122 debugging information entry, 
123 used to describe \addtoindex{COBOL} level 88 conditions, which 
124 is described in abstract terms rather than COBOL-specific terms.  
125 Conceivably, this TAG might be used with a different language 
126 which had similar functionality. 
127
128 \subsection{Architecture Independence}
129 DWARF can be used with a wide range of processor architectures, 
130 whether byte or word oriented, linear or segmented, with any 
131 word or byte size.  DWARF can be used with Von Neumann architectures, 
132 using a single address space for both code and data; Harvard 
133 architectures, with separate code and data address spaces; and 
134 potentially for other architectures such as DSPs with their 
135 idiosyncratic memory organizations.  DWARF can be used with 
136 common register-oriented architectures or with stack architectures. 
137
138 DWARF assumes that memory has individual units (words or bytes) 
139 which have unique addresses which are ordered.  (Some architectures 
140 like the i386 can represent the same physical machine location with 
141 different segment and offset pairs.  Identifying aliases is an 
142 implementation issue.)
143
144 \needlines{6}
145 \subsection{Operating System Independence}
146 DWARF is widely associated with SVR4 Unix and similar operating 
147 systems like BSD and Linux.  DWARF fits well with the section 
148 organization of the ELF object file format. Nonetheless, DWARF 
149 attempts to be independent of either the OS or the object file 
150 format.  There have been implementations of DWARF debugging 
151 data in COFF, Mach-O and other object file formats. 
152
153 DWARF assumes that any object file format will be able to 
154 distinguish the various DWARF data sections in some fashion, 
155 preferably by name. 
156
157 DWARF makes a few assumptions about functionality provided by 
158 the underlying operating system.  DWARF data sections can be 
159 read sequentially and independently.
160 Each DWARF data section is a sequence of 8-bit bytes, 
161 numbered starting with zero.  The presence of offsets from one 
162 DWARF data section into other data sections does not imply that 
163 the underlying OS must be able to position files randomly; a 
164 data section could be read sequentially and indexed using the offset. 
165
166 \subsection{Compact Data Representation} 
167 The DWARF description is designed to be a compact file-oriented 
168 representation. 
169
170 There are several encodings which achieve this goal, such as the 
171 TAG and attribute abbreviations or the line number encoding.  
172 References from one section to another, especially to refer to 
173 strings, allow these sections to be compacted to eliminate 
174 duplicate data. 
175
176 There are multiple schemes for eliminating duplicate data or 
177 reducing the size of the DWARF debug data associated with a 
178 given file.  These include COMDAT, used to eliminate duplicate 
179 function or data definitions, the split DWARF object files 
180 which allow a consumer to find DWARF data in files other than 
181 the executable, or the type units, which allow similar type 
182 definitions from multiple compilations to be combined. 
183
184 In most cases, it is anticipated that DWARF 
185 debug data will be read by a consumer (usually a debugger) and 
186 converted into a more efficiently accessed internal representation.  
187 For the most part, the DWARF data in a section is not the same as 
188 this internal representation.
189
190 \needlines{4}
191 \subsection{Efficient Processing} 
192 DWARF is designed to be processed efficiently, so that a 
193 producer (a compiler) can generate the debug descriptions 
194 incrementally and a consumer can read only the descriptions 
195 which it needs at a given time. The data formats are designed 
196 to be efficiently interpreted by a consumer.
197
198 As mentioned, there is a tension between this objective and 
199 the preceding one.  A DWARF data representation which resembles 
200 an internal data representation may lead to faster processing, 
201 but at the expense of larger data files. This may also constrain 
202 the possible implementations.
203
204 \subsection{Implementation Independence}
205 DWARF attempts to allow developers the greatest flexibility 
206 in designing implementations, without mandating any particular 
207 design decisions. Issues which can be described as 
208 quality-of-implementation are avoided.
209
210 \subsection{Explicit Rather Than Implicit Description}
211 DWARF describes the source to object translation explicitly 
212 rather than using common practice or convention as an implicit 
213 understanding between producer and consumer.  For example, where 
214 other debugging formats assume that a debugger knows how to 
215 virtually unwind the stack, moving from one stack frame to the next using 
216 implicit knowledge about the architecture or operating system, 
217 DWARF makes this explicit in the Call Frame Information description.
218
219 \subsection{Avoid Duplication of Information}
220 DWARF has a goal of describing characteristics of a program once, 
221 rather than repeating the same information multiple times.  The 
222 string sections can be compacted to eliminate duplicate strings, 
223 for example.  Other compaction schemes or references between 
224 sections support this. Whether a particular implementation is 
225 effective at eliminating duplicate data, or even attempts to, 
226 is a quality-of-implementation issue.  
227
228 \needlines{6}
229 \subsection{Leverage Other Standards}
230 Where another standard exists which describes how to interpret 
231 aspects of a program, DWARF defers to that standard rather than 
232 attempting to duplicate the description.  For example, C++ has 
233 specific rules for deciding which function to call depending 
234 name, scope, argument types, and other factors.  DWARF describes 
235 the functions and arguments, but doesn't attempt to describe 
236 how one would be selected by a consumer performing any particular 
237 operation.
238
239 \subsection{Limited Dependence on Tools}
240 DWARF data is designed so that it can be processed by commonly 
241 available assemblers, linkers, and other support programs, 
242 without requiring additional functionality specifically to 
243 support DWARF data.  This may require the implementer to be 
244 careful that they do not generate DWARF data which cannot be 
245 processed by these programs.  Conversely, an assembler which 
246 can generate LEB128 (Little-Endian Base 128) 
247 values may allow the compiler to generate 
248 more compact descriptions, and a linker which understands the 
249 format of string sections can merge these sections.  Whether 
250 or not an implementation includes these functions is a 
251 quality-of-implementation issue, not mandated by the DWARF 
252 specification.
253
254 \subsection{Separate Description From Implementation}
255 DWARF intends to describe the translation of a program from 
256 source to object, while neither mandating any particular design 
257 nor making any other design difficult.  For example, DWARF 
258 describes how the arguments and local variables in a function 
259 are to be described, but doesn't specify how this data is 
260 collected or organized by a producer.  Where a particular DWARF 
261 feature anticipates that it will be implemented in a certain 
262 fashion, informative text will suggest but not require this design.
263
264 \subsection{Permissive Rather Than Prescriptive}
265 The DWARF Standard specifies the meaning of DWARF descriptions. It does not
266 specify in detail what a particular producer must generate for any source to
267 object conversion.  One producer may generate a more complete description
268 than another, it may describe features in a different order (unless the 
269 standard explicitly requires a particular order), or it may use
270 different abbreviations or compression methods.  Similarly, DWARF does not
271 specify exactly what a particular consumer should do with each part of the
272 description, although we believe that the potential uses for each description
273 should be evident.
274
275 DWARF is permissive, allowing different producers to generate different
276 descriptions for the same source to object conversion, and permitting
277 different consumers to provide more or less functionality or information
278 to the user.  This may result in debugging information being larger or
279 smaller, compilers or debuggers which are faster or slower, and more or
280 less functional.  These are described as differences in 
281 quality-of-implementation.
282
283 Each producer conforming to the DWARF standard must follow the format and
284 meaning as specified in the standard.  As long as the DWARF description
285 generated follows this specification, the producer is generating valid DWARF.
286 For example, DWARF allows a producer to identify the end of a function
287 prologue in the Line Information so that a debugger can stop at this location.
288 A producer which does this is generating valid DWARF, as is another which
289 doesn't.  As another example, one producer may generate descriptions
290 for variables which are moved from memory to a register in a certain range,
291 while another may only describe the variable's location in memory.  Both are
292 valid DWARF descriptions, while a consumer using the former would be able
293 to provide more accurate values for the variable while executing in that
294 range than a consumer using the latter.
295
296 In this document, where the word \doublequote{may} is used, the producer has 
297 the option to follow the description or not.  Where the text says 
298 \doublequote{may not}, this is prohibited.  Where the text says \doublequote{should}, 
299 this is advice about best practice, but is not a requirement.
300
301 \subsection{Vendor Extensibility}
302 This document does not attempt to cover all interesting
303 languages or even to cover all of the possible debugging
304 information needs for its primary target languages. 
305 Therefore,
306 the document provides vendors a way to define their own
307 debugging information tags, attributes, base type encodings,
308 location operations, language names, calling conventions and
309 call frame instructions by reserving a subset of the valid
310 values for these constructs for vendor specific additions
311 and defining related naming conventions. 
312 Vendors may also use
313 debugging information entries and attributes defined here in
314 new situations. 
315 Future versions of this document will not use
316 names or values reserved for vendor specific additions. 
317 All names and values not reserved for vendor additions, however,
318 are reserved for future versions of this document.
319
320 \needlines{4}
321 Where this specification provides a means for
322 describing the source language, implementors are expected
323 to adhere to that specification. 
324 For language features that
325 are not supported, implementors may use existing attributes
326 in novel ways or add vendor-defined attributes. 
327 Implementors
328 who make extensions are strongly encouraged to design them
329 to be compatible with this specification in the absence of
330 those extensions.
331
332 \needlines{4}
333 The DWARF format is organized so that a consumer can skip over
334 data which it does not recognize. This may allow a consumer
335 to read and process files generated according to a later
336 version of this standard or which contain vendor extensions,
337 albeit possibly in a degraded manner.
338
339 \section{Changes from Version 4 to Version 5}
340 \addtoindexx{DWARF Version 5}
341 The following is a list of the major changes made to the 
342 DWARF Debugging Information Format since Version 4 was published. 
343 The list is not meant to be exhaustive.
344 \begin{itemize}
345 \item Eliminate the \dotdebugtypes{}
346 section introduced in \DWARFVersionIV{} 
347 and move its contents into the \dotdebuginfo{} section.
348 \item Add support for collecting common DWARF information 
349 (debugging information entries and macro definitions)
350 across multiple executable and shared files and keeping it in a single
351 \addtoindex{supplementary object file}.
352 \needlines{6}
353 \item Replace the line number program header format with a new 
354 format that 
355 provides the ability to use an MD5 hash to validate 
356 the source file version in use, allows pooling 
357 of directory and file name strings and makes provision for vendor-defined
358 extensions. Also add a string section specific to the line number table 
359 (\dotdebuglinestr)
360 to properly support the common practice of stripping all DWARF sections
361 except for line number information.
362 \needlines{4}
363 \item Add a split object file and package representations to allow most 
364 DWARF information to be kept separate from an executable 
365 or shared image. This includes new sections 
366 \dotdebugaddr, \dotdebugstroffsets, \dotdebugabbrevdwo, \dotdebuginfodwo, 
367 \dotdebuglinedwo, \dotdebugloclistsdwo, \dotdebugmacrodwo, \dotdebugstrdwo,
368 \dotdebugstroffsetsdwo, \dotdebugcuindex{} and \dotdebugtuindex{} 
369 together with new forms of attribute value for referencing these sections.
370 This enhances DWARF support by reducing executable program size and
371 by improving link times.
372 \item Replace the \dotdebugmacinfo{} macro information representation with
373 with a \dotdebugmacro{} representation that can potentially be much more compact.
374 \item Replace the \dotdebugpubnames{} and \dotdebugpubtypes{} sections
375 with a single and more functional name index section, \dotdebugnames{}.
376 \needlines{4}
377
378 \item Replace the location list and range list sections (\texttt{.debug\_loc} 
379 and \texttt{.debug\_ranges}, respectively) with new sections (\dotdebugloclists{} 
380 and \dotdebugrnglists) and new representations that
381 save space and processing time by eliminating most related
382 object file relocations.
383
384 \item Add a new debugging information entry (\DWTAGcallsiteNAME), related 
385 attributes and DWARF expression operators to describe call site information, 
386 including identification of tail calls and tail recursion.
387 \item Add improved support for \addtoindex{FORTRAN} assumed rank arrays 
388 (\DWTAGgenericsubrangeNAME), dynamic rank arrays (\DWATrankNAME)
389 and co-arrays (\DWTAGcoarraytypeNAME{}).
390 \item Add new operations that allow support for 
391 a DWARF expression stack containing typed values.
392 \item Add improved support for the \addtoindex{C++}:
393 \texttt{auto} return type, deleted member functions (\DWATdeletedNAME), 
394 as well as defaulted constructors and destructors (\DWATdefaultedNAME).
395 \item Add a new attribute (\DWATnoreturnNAME{}), to identify 
396 a subprogram that does not return to its caller.
397 \item Add language codes for C 2011, C++ 2003, C++ 2011, C++ 2014,
398 Dylan, Fortran 2003, Fortran 2008, Go, Haskell, 
399 Julia, Modula 3, Ocaml, OpenCL, Rust and Swift.
400 \item Numerous other more minor additions to improve functionality
401 and performance.
402 \end{itemize}
403
404 DWARF Version 5 is compatible with DWARF Version 4 except as follows:
405 \begin{itemize}
406 \item The compilation unit header (in the \dotdebuginfo{} section) has
407 a new \HFNunittype{} field.
408 \bb
409 In addition, the \HFNdebugabbrevoffset{} and \HFNaddresssize{} fields are reordered.
410 \eb
411 \needlines{4}
412 \item New operand forms for attribute values are defined 
413 (\DWFORMaddrxNAME, 
414 \bb
415 \DWFORMaddrxoneNAME, \DWFORMaddrxtwoNAME, \DWFORMaddrxthreeNAME, \DWFORMaddrxfourNAME, 
416 \eb
417 \DWFORMdatasixteenNAME, \DWFORMimplicitconstNAME, 
418 \DWFORMlinestrpNAME,
419 \DWFORMloclistxNAME, \DWFORMrnglistxNAME,
420 \bb
421 \DWFORMrefsupfourNAME, \DWFORMrefsupeightNAME, 
422 \eb
423 \DWFORMstrpsupNAME, \DWFORMstrxNAME, 
424 \bb
425 \DWFORMstrxoneNAME, \DWFORMstrxtwoNAME, \DWFORMstrxthreeNAME{} and \DWFORMstrxfourNAME.
426 \eb
427
428 \textit{Because a pre-DWARF Version 5 consumer will not be able to interpret 
429 these even to ignore and skip over them, new forms must be 
430 considered incompatible additions.}
431 \item The line number table header is substantially revised.
432 \needlines{4}
433 \item 
434 \bb
435 The \dotdebugloc{} and \dotdebugranges{} sections are replaced
436 by new \dotdebugloclists{} and \dotdebugrnglists{} sections, respectively.
437 These new sections have a new (and more efficient) list structure.
438 Attributes that reference the predecessor sections must be interpreted
439 differently to access the new sections. The new sections encode the same
440 information as their predecessors, except that a new default location 
441 list entry is added. 
442 \eb
443 \item In a string type, the \DWATbytesizeNAME{} attribute is re-defined 
444 to always describe the size of the string type. 
445 (Previously it described the size of the optional string length data 
446 field if the \DWATstringlengthNAME{} attribute was also present.)
447 \bb
448 In addition, the \DWATstringlengthNAME{} attribute may now refer directly
449 to an object that contains the length value.
450 \eb
451 \end{itemize}
452
453 While not strictly an incompatibility, the macro information 
454 representation is completely new; further, producers 
455 and consumers may optionally continue to support the older 
456 representation. While the two representations cannot both be 
457 used in the same compilation unit, they can co-exist in 
458 executable or shared images.
459
460 Similar comments apply to replacement of the \dotdebugpubnames{} 
461 and \dotdebugpubtypes{} sections with the new \dotdebugnames{} 
462 section.
463 \bbeb
464
465 \needlines{4}
466 \section{Changes from Version 3 to Version 4}
467 \addtoindexx{DWARF Version 4}
468 The following is a list of the major changes made to the 
469 DWARF Debugging Information Format since Version 3 was 
470 published. The list is not meant to be exhaustive.
471 \begin{itemize}
472 \item Reformulate 
473 Section 2.6 (Location Descriptions) 
474 to better distinguish DWARF location descriptions, which
475 compute the location where a value is found (such as an 
476 address in memory or a register name) from DWARF expressions, 
477 which compute a final value (such as an array bound).
478 \item Add support for bundled instructions on machine architectures 
479 where instructions do not occupy a whole number of bytes.
480 \item Add a new attribute form for section offsets, 
481 \DWFORMsecoffsetNAME,\addtoindexx{section offset}
482 to replace the use of 
483 \DWFORMdatafourNAME{} and \DWFORMdataeightNAME{} for section offsets.
484 \item Add an attribute, \DWATmainsubprogramNAME, to identify the main subprogram of a
485 program.
486 \item Define default array lower bound values for each supported language.
487 \item Add a new technique using separate type units, type signatures and \COMDAT{} sections to
488 improve compression and duplicate elimination of DWARF information.
489 \item Add support for new \addtoindex{C++} language constructs, including rvalue references, generalized
490 constant expressions, Unicode character types and template aliases.
491 \item Clarify and generalize support for packed arrays and structures.
492 \item Add new line number table support to facilitate profile based compiler optimization.
493 \item Add additional support for template parameters in instantiations.
494 \item Add support for strongly typed enumerations in languages (such as \addtoindex{C++}) that have two
495 kinds of enumeration declarations.
496 \item 
497 \bb
498 Add the option for the \DWAThighpc{} value of a program unit or scope to be 
499 specified as a constant offset relative to the corresponding \DWATlowpc{} value.
500 \eb
501 \end{itemize}
502 \addtoindex{DWARF Version 4} is compatible with 
503 \addtoindex{DWARF Version 3} except as follows:
504 \begin{itemize}
505 \item DWARF attributes that use any of the new forms of attribute value representation (for
506 section offsets, flag compression, type signature references, and so on) cannot be read by
507 \addtoindex{DWARF Version 3}
508 consumers because the consumer will not know how to skip over the
509 unexpected form of data.
510 \item DWARF frame and line number table sections include additional fields that affect the location
511 and interpretation of other data in the section.
512 \end{itemize}
513
514 \section{Changes from Version 2 to Version 3}
515 \addtoindexx{DWARF Version 3}
516 The following is a list of the major differences between
517 Version 2 and Version 3 of the DWARF Debugging Information
518 Format. The list is not meant to be exhaustive.
519 \begin{itemize}
520 \item
521 Make provision for DWARF information files that are larger
522 than 4 GBytes.
523 \item
524 Allow attributes to refer to debugging information entries
525 in other shared libraries.
526 \item
527 Add support for \addtoindex{Fortran 90} modules as well as allocatable
528 array and pointer types.
529 \item
530 Add additional base types for \addtoindex{C} (as revised for 1999).
531 \item
532 Add support for \addtoindex{Java} and \addtoindex{COBOL}.
533 \item
534 Add namespace support for \addtoindex{C++}.
535 \item
536 Add an optional section for global type names (similar to
537 the global section for objects and functions).
538 \item
539 Adopt \addtoindex{UTF-8} as the preferred representation of program name strings.
540 \item
541 Add improved support for optimized code (discontiguous
542 scopes, end of prologue determination, multiple section
543 code generation).  
544 \item Improve the ability to eliminate
545 duplicate DWARF information during linking.  
546 \end{itemize}
547
548 \addtoindex{DWARF Version 3}
549 is compatible with 
550 \addtoindex{DWARF Version 2} except as follows:
551 \begin{itemize}
552 \item
553 Certain very large values of the initial length fields that
554 begin DWARF sections as well as certain structures are reserved
555 to act as escape codes for future extension; one such extension
556 is defined to increase the possible size of DWARF descriptions
557 (see Section \refersec{datarep:32bitand64bitdwarfformats}).
558 \item
559 References that use the attribute form 
560 \DWFORMrefaddrNAME{}
561 are specified to be four bytes in the DWARF 32-bit format and
562 eight bytes in the DWARF 64-bit format, while 
563 \addtoindex{DWARF Version 2} 
564 specifies that such references have the same size as an
565 address on the target system (see Sections 
566 \refersec{datarep:32bitand64bitdwarfformats} and 
567 \refersec{datarep:attributeencodings}).
568 \item
569 The return\_address\_register field in a Common Information
570 Entry record for call frame information is changed to unsigned
571 LEB representation (see Section 
572 \refersec{chap:structureofcallframeinformation}).
573 \end{itemize}
574
575 \section{Changes from Version 1 to Version 2}
576 \addtoindex{DWARF Version 2} 
577 describes the second generation of debugging
578 information based on the DWARF format. While 
579 \addtoindex{DWARF Version 2}
580 provides new debugging information not available in
581 Version 1, the primary focus of the changes for Version
582 2 is the representation of the information, rather than
583 the information content itself. The basic structure of
584 the Version 2 format remains as in Version 1: the debugging
585 information is represented as a series of debugging information
586 entries, each containing one or more attributes (name/value
587 pairs). The Version 2 representation, however, is much more
588 compact than the Version 1 representation. In some cases,
589 this greater density has been achieved at the expense of
590 additional complexity or greater difficulty in producing and
591 processing the DWARF information. The definers believe that the
592 reduction in I/O and in memory paging should more than make
593 up for any increase in processing time.  
594
595 \needlines{5}
596 The representation
597 of information changed from Version 1 to Version 2, so that
598 Version 2 DWARF information is not binary compatible with
599 Version 1 information. To make it easier for consumers to
600 support both Version 1 and Version 2 DWARF information, the
601 Version 2 information has been moved to a different object
602 file section, \dotdebuginfo{}.  
603
604 \textit{
605 A summary of the major changes made in 
606 \addtoindex{DWARF Version 2}
607 compared to the DWARF Version 1 may be found in the 
608 \addtoindex{DWARF Version 2}
609 document.
610 }
611