f354441fcdaa100bee29543fad7e6dab5ca2805a
[dwarf-doc.git] / dwarf5 / latexdoc / splitobjects.tex
1 \chapter[Split DWARF Objects (Informative)]{Split DWARF Objects (Informative)}
2 \label{app:splitdwarfobjectsinformative}
3 \addtoindexx{DWARF compression}
4 \addtoindex{DWARF duplicate elimination}
5 With the traditional DWARF format, debug information is designed
6 with the expectation that it will be processed by the linker to
7 produce an output binary with complete debug information, and
8 with fully-resolved references to locations within the
9 application. For very large applications, however, this approach
10 can result in excessively large link times and excessively large
11 output files. 
12
13 Several vendors have independently developed
14 proprietary approaches that allow the debug information to remain
15 in the relocatable object files, so that the linker does not have
16 to process the debug information or copy it to the output file.
17 These approaches have all required that additional information be
18 made available to the debug information consumer, and that the
19 consumer perform some minimal amount of relocation in order to
20 interpret the debug info correctly. The additional information
21 required, in the form of load maps or symbol tables, and the
22 details of the relocation are not covered by the DWARF
23 specification, and vary with each vendor's implementation.
24
25 These limitations are removed by the design described here.
26
27 \section{Overview}
28 \label{app:splitoverview}
29 \DWARFVersionV{} introduces an optional set of debugging sections
30 that allow the compiler to partition the debugging information
31 into a set of (small) sections that require link-time relocation
32 and a set of (large) sections that do not. The sections that
33 require relocation are written to the relocatable object file as
34 usual, and are linked into the final executable. The sections
35 that do not require relocation, however, can be written to the
36 relocatable object (.o) file but ignored by the linker, or they
37 can be written to a separate DWARF object (.dwo{}) 
38 \addtoindexx{\texttt{.dwo} file extension} file.
39
40 \needlines{4}
41 The optional set of debugging sections includes the following:
42 \begin{itemize}
43 \item
44 \dotdebuginfodwo{} - Contains the \DWTAGcompileunit{} and
45 \DWTAGtypeunit{} DIEs and
46 their descendants. This is the bulk of the debugging
47 information for the compilation unit that is normally found
48 in the \dotdebuginfo{} section.
49 \item
50 \dotdebugabbrevdwo{} - Contains the abbreviations tables used by
51 the \dotdebuginfodwo{} sections.
52 \item
53 \dotdebuglocdwo{} - Contains the location lists referenced by
54 the debugging information entries in the \dotdebuginfodwo{}
55 section. This contains the location lists normally found in 
56 the \dotdebugloc{} section,
57 with a slightly modified format to eliminate the need for
58 relocations.
59 \item
60 \dotdebugstrdwo{} - Contains the string table for all indirect
61 strings referenced by the debugging information in the
62 \dotdebuginfodwo{} sections.
63 \item
64 \dotdebugstroffsetsdwo{} - Contains the string offsets table
65 for the strings in the \dotdebugstrdwo{}{} section.
66 \item
67 \dotdebugmacrodwo{} - Contains macro definition information,
68 normally found in the \dotdebugmacro{} section.
69 \item
70 \dotdebuglinedwo{} - Contains skeleton line number tables for the type
71 units in the \dotdebuginfodwo{} section. These tables
72 contain only the directory and filename lists needed to
73 interpret \DWATdeclfile{} attributes in the debugging
74 information entries. Actual line number tables remain in the
75 \dotdebugline{} section, and remain in the relocatable object
76 (.o) files.
77
78 In a .dwo file there is no benefit to having a separate string
79 section for directories and file names because the primary
80 string table will never be stripped. Accordingly, no
81 \texttt{.debug\_line\_str.dwo} is defined. Content descriptions corresponding
82 to \DWFORMlinestrp{} in an executable file (for example, in the
83 skeleton compilation unit) instead use \DWFORMstrx. This allows
84 directory and file name strings to be merged with general
85 strings and across compilations in package files (which are not
86 subject to potential stripping).
87
88 \end{itemize}
89
90 In order for the consumer to locate and process the debug
91 information, the compiler must produce a small amount of debug
92 information that passes through the linker into the output
93 binary. A skeleton \dotdebuginfo{} section for each compilation unit
94 contains a reference to the corresponding ".o" or ".dwo"
95 file, and the \dotdebugline{} section (which is typically small
96 compared to the \dotdebuginfo{} sections) is
97 linked into the output binary, as is the new \dotdebugaddr{}
98 section.
99
100 \needlines{6}
101 The debug sections that continue to be linked into the
102 output binary include the following:
103 \begin{itemize}
104 \item
105 \dotdebugabbrev{} - Contains the abbreviation codes used by the
106 skeleton \dotdebuginfo{} section.
107 \item
108 \dotdebuginfo{} - Contains a skeleton \DWTAGcompileunit{} DIE,
109 but no children.
110 \item
111 \dotdebugstr{} - Contains any strings referenced by the skeleton
112 \dotdebuginfo{} sections (via \DWFORMstrp{} or \DWFORMstrx{}).
113 \item
114 \dotdebugstroffsets{} - Contains the string offsets table for
115 the strings in the \dotdebugstr{} section.
116 \item
117 \dotdebugaddr{} - Contains references to loadable sections,
118 indexed by attributes of form \DWFORMaddrx{} or location
119 expression \DWOPaddrx{} opcodes.
120 \item
121 \dotdebugline{} - Contains the line number tables, unaffected by
122 this design. (These could be moved to the .dwo file, but in
123 order to do so, each \DWLNEsetaddress{} opcode would need to
124 be replaced by a new opcode that referenced an entry in the
125 \dotdebugaddr{} section. Furthermore, leaving this section in the
126 .o file allows many debug info consumers to remain unaware of
127 .dwo files.)
128 \item
129 \dotdebugframe{} - Contains the frame tables, unaffected by this
130 design.
131 \item
132 \dotdebugranges{} - Contains the range lists, unaffected by this
133 design.
134 \item
135 \dotdebugpubnames{} - Contains the public names for use in
136 building an index section. This section has the same
137 format and use as always. The section header refers to a
138 compilation unit offset, which is the offset of the
139 skeleton compilation unit in the \dotdebuginfo{} section.
140 \item
141 \dotdebugpubtypes{} - Contains the public types for use in
142 building an index section. This section has the same
143 format and use as always. The section header refers to a
144 compilation unit offset, which is the offset of the
145 skeleton compilation unit in the \dotdebuginfo{} section.
146 \item
147 \dotdebugaranges{} - Contains the accelerated range lookup table
148 for the compilation unit, unaffected by this design.
149 \end{itemize}
150
151 \needlines{6}
152 The skeleton \DWTAGcompileunit{} DIE has the following attributes:
153 \autocols[0pt]{c}{3}{l}{
154 \DWATaddrbase{},
155 \DWATcompdir{},
156 \DWATdwoname{},
157 \DWATdwoid{},
158 \DWAThighpc{} \dag,
159 \DWATlowpc{} \dag,
160 \DWATranges{} \dag,
161 \DWATrangesbase{},
162 \DWATstmtlist{},
163 \DWATstroffsetsbase{}
164 }
165 \dag{} If \DWATranges{} is present, \DWATlowpc{} and \DWAThighpc{} are
166 not used, and vice versa.
167
168 All other attributes of the compilation unit DIE are moved to
169 the full DIE in the \dotdebuginfodwo{} section.
170
171 \needlines{4}
172 Because of other improvements in \DWARFVersionV, most of the
173 relocations that would normally be found in the \dotdebuginfodwo{}
174 sections are moved to the \dotdebugaddr{} and
175 \dotdebugstroffsetsdwo{} sections. Those in the
176 \dotdebugstroffsetsdwo{} sections are simply omitted because the
177 DWARF information in those sections is not combined at link
178 time, so no relocation is necessary. Similarly,
179 many of the remaining relocations referring to range lists are
180 eliminated. 
181
182 The relocations that remain fall into the following categories:
183 \begin{itemize}
184 \item
185 References from compilation unit and type unit headers to the
186 \dotdebugabbrevdwo{} section. Because the new sections are not
187 combined at link time, these references need no relocations.
188 \item
189 References from \DWTAGcompileunit{} DIEs to the
190 \dotdebuglinedwo{} section, via \DWATstmtlist{}. This attribute
191 remains in the skeleton \dotdebuginfo{} section, so no
192 relocation in the \dotdebuginfodwo{} section is necessary.
193 \item
194 References from \DWTAGtypeunit{} DIEs to the skeleton
195 \dotdebuglinedwo{} section, via \DWATstmtlist{}. Because the new
196 sections are not combined at link time, these references need
197 no relocations.
198 \item
199 References from \DWTAGcompileunit{} and \DWTAGtypeunit{} DIEs
200 to the \dotdebugstroffsetsdwo{} section, via
201 \DWATstroffsetsbase{}. Because the new sections are not
202 combined at link time, the \DWATstroffsetsbase{} attribute
203 is not required in a \dotdebuginfodwo{}
204 section.
205 \item
206 References from \DWTAGcompileunit{} DIEs to the \dotdebugaddr{}
207 section, via \DWATaddrbase{}. This attribute remains in
208 the skeleton \dotdebuginfo{} section, so no relocation in the
209 \dotdebuginfodwo{} section is necessary.
210 \needlines{4}
211 \item
212 References from \DWTAGcompileunit{} DIEs to the \dotdebugranges{}
213 section, via \DWATrangesbase{}. This attribute remains in
214 the skeleton \dotdebuginfo{} section, so no relocation in the
215 \dotdebuginfodwo{} section is necessary.
216 \item
217 References from the \dotdebuglocdwo{} section to machine addresses
218 via a location list entry or a base address selection entry.
219 With a minor change to the location list entry format,
220 described below, these relocations are also eliminated.
221 \end{itemize}
222
223 \needlines{4}
224 Each location list entry contains beginning and ending address
225 offsets, which normally may be relocated addresses. In the
226 \dotdebuglocdwo{} section, these offsets are replaced by indices
227 into the \dotdebugaddr{} section. Each location list entry begins
228 with a single byte identifying the entry type:
229 \begin{itemize}
230 \item
231 \DWLLEendoflistentry{} (0) indicates an end-of-list entry,
232 \item
233 \DWLLEbaseaddressselectionentry{} (1) indicates a base address
234 selection entry, 
235 \item
236 \DWLLEstartendentry{} (2) indicates a normal
237 location list entry providing start and end addresses,
238 \item
239 \DWLLEstartlengthentry{} (3) indicates a normal location list
240 entry providing a start address and a length, and
241 \item
242 \DWLLEoffsetpairentry{} (4) indicates a normal location list
243 entry providing start and end offsets relative to the base
244 address. 
245 \end{itemize}
246 An end-of-list entry has no further data. A base address
247 selection entry contains a single unsigned LEB128
248 \addtoindexx{LEB128!unsigned} number
249 following the entry type byte, which is an index into the
250 \dotdebugaddr{} section that selects the new base address for
251 subsequent location list entries. A start/end entry contains two
252 unsigned LEB128\addtoindexx{LEB128!unsigned} numbers 
253 following the entry type byte, which are
254 indices into the \dotdebugaddr{} section that select the beginning
255 and ending addresses. A start/length entry contains one unsigned
256 LEB128 number and a 4-byte unsigned value (as would be
257 represented by the form code \DWFORMdatafour). The first number
258 is an index into the \dotdebugaddr{} section that selects the
259 beginning offset, and the second number is the length of the
260 range. Addresses fetched from the \dotdebugaddr{} section are not
261 relative to the base address. An offset pair entry contains two
262 4-byte unsigned values (as would be represented by the form code
263 \DWFORMdatafour){}, treated as the beginning and ending offsets,
264 respectively, relative to the base address. As in the \dotdebugloc{}
265 section, the base address is obtained either from the nearest
266 preceding base address selection entry, or, if there is no such
267 entry, from the compilation unit base address (as defined in
268 Section 3.1.1). For the latter three types (start/end,
269 start/length, and offset pair), the two operand values are
270 followed by a location description as in a normal location list
271 entry in the \dotdebugloc{} section.
272
273 This design depends on having an index of debugging information
274 available to the consumer. For name lookups, the consumer can use
275 the \dotdebugpubnames{} and \dotdebugpubtypes{} sections (or an index
276 built at link time based on the information in those sections),
277 which will lead to a skeleton compilation unit. The
278 \DWATcompdir{} and \DWATdwoname{} attributes in the skeleton
279 compilation unit can then be used to locate the corresponding
280 DWARF object file for the compilation unit. Similarly, for an
281 address lookup, the consumer can use the \dotdebugaranges{} table,
282 which will also lead to a skeleton compilation unit. For a file
283 and line number lookup, the skeleton compilation units can be
284 used to locate the line number tables.
285
286 \section{Split DWARF Object Examples}
287 \label{app:splitdwarfobjectexamples}
288
289 [TBD]
290
291 \section{DWARF Package File Example}
292 \label{app:dwarfpackagefileexample}
293 \addtoindex{DWARF duplicate elimination!examples}
294 [TBD]