[8833] | 1 | Notes on the GNU Implementation of DWARF Debugging Information |
---|
| 2 | -------------------------------------------------------------- |
---|
| 3 | Last Updated: Sun Jul 17 08:17:42 PDT 1994 by rfg@segfault.us.com |
---|
| 4 | ------------------------------------------------------------ |
---|
| 5 | |
---|
| 6 | This file describes special and unique aspects of the GNU implementation |
---|
| 7 | of the DWARF debugging information language, as provided in the GNU version |
---|
| 8 | 2.x compiler(s). |
---|
| 9 | |
---|
| 10 | For general information about the DWARF debugging information language, |
---|
| 11 | you should obtain the DWARF version 1 specification document (and perhaps |
---|
| 12 | also the DWARF version 2 draft specification document) developed by the |
---|
| 13 | UNIX International Programming Languages Special Interest Group. A copy |
---|
| 14 | of the the DWARF version 1 specification (in PostScript form) may be |
---|
| 15 | obtained either from me <rfg@netcom.com> or from the main Data General |
---|
| 16 | FTP server. (See below.) The file you are looking at now only describes |
---|
| 17 | known deviations from the DWARF version 1 specification, together with |
---|
| 18 | those things which are allowed by the DWARF version 1 specification but |
---|
| 19 | which are known to cause interoperability problems (e.g. with SVR4 SDB). |
---|
| 20 | |
---|
| 21 | To obtain a copy of the DWARF Version 1 and/or DWARF Version 2 specification |
---|
| 22 | from Data General's FTP server, use the following procedure: |
---|
| 23 | |
---|
| 24 | --------------------------------------------------------------------------- |
---|
| 25 | ftp to machine: "dg-rtp.dg.com" (128.222.1.2). |
---|
| 26 | |
---|
| 27 | Log in as "ftp". |
---|
| 28 | cd to "plsig" |
---|
| 29 | get any of the following file you are interested in: |
---|
| 30 | |
---|
| 31 | dwarf.1.0.3.ps |
---|
| 32 | dwarf.2.0.0.index.ps |
---|
| 33 | dwarf.2.0.0.ps |
---|
| 34 | --------------------------------------------------------------------------- |
---|
| 35 | |
---|
| 36 | The generation of DWARF debugging information by the GNU version 2.x C |
---|
| 37 | compiler has now been tested rather extensively for m88k, i386, i860, and |
---|
| 38 | Sparc targets. The DWARF output of the GNU C compiler appears to inter- |
---|
| 39 | operate well with the standard SVR4 SDB debugger on these kinds of target |
---|
| 40 | systems (but of course, there are no guarantees). |
---|
| 41 | |
---|
| 42 | DWARF generation for the GNU g++ compiler is still not operable. This is |
---|
| 43 | due primarily to the many remaining cases where the g++ front end does not |
---|
| 44 | conform to the conventions used in the GNU C front end for representing |
---|
| 45 | various kinds of declarations in the TREE data structure. It is not clear |
---|
| 46 | at this time how these problems will be addressed. |
---|
| 47 | |
---|
| 48 | Future plans for the dwarfout.c module of the GNU compiler(s) includes the |
---|
| 49 | addition of full support for GNU FORTRAN. (This should, in theory, be a |
---|
| 50 | lot simpler to add than adding support for g++... but we'll see.) |
---|
| 51 | |
---|
| 52 | Many features of the DWARF version 2 specification have been adapted to |
---|
| 53 | (and used in) the GNU implementation of DWARF (version 1). In most of |
---|
| 54 | these cases, a DWARF version 2 approach is used in place of (or in addition |
---|
| 55 | to) DWARF version 1 stuff simply because it is apparent that DWARF version |
---|
| 56 | 1 is not sufficiently expressive to provide the kinds of information which |
---|
| 57 | may be necessary to support really robust debugging. In all of these cases |
---|
| 58 | however, the use of DWARF version 2 features should not interfere in any |
---|
| 59 | way with the interoperability (of GNU compilers) with generally available |
---|
| 60 | "classic" (pre version 1) DWARF consumer tools (e.g. SVR4 SDB). |
---|
| 61 | |
---|
| 62 | The DWARF generation enhancement for the GNU compiler(s) was initially |
---|
| 63 | donated to the Free Software Foundation by Network Computing Devices. |
---|
| 64 | (Thanks NCD!) Additional development and maintenance of dwarfout.c has |
---|
| 65 | been largely supported (i.e. funded) by Intel Corporation. (Thanks Intel!) |
---|
| 66 | |
---|
| 67 | If you have questions or comments about the DWARF generation feature, please |
---|
| 68 | send mail to me <rfg@netcom.com>. I will be happy to investigate any bugs |
---|
| 69 | reported and I may even provide fixes (but of course, I can make no promises). |
---|
| 70 | |
---|
| 71 | The DWARF debugging information produced by GCC may deviate in a few minor |
---|
| 72 | (but perhaps significant) respects from the DWARF debugging information |
---|
| 73 | currently produced by other C compilers. A serious attempt has been made |
---|
| 74 | however to conform to the published specifications, to existing practice, |
---|
| 75 | and to generally accepted norms in the GNU implementation of DWARF. |
---|
| 76 | |
---|
| 77 | ** IMPORTANT NOTE ** ** IMPORTANT NOTE ** ** IMPORTANT NOTE ** |
---|
| 78 | |
---|
| 79 | Under normal circumstances, the DWARF information generated by the GNU |
---|
| 80 | compilers (in an assembly language file) is essentially impossible for |
---|
| 81 | a human being to read. This fact can make it very difficult to debug |
---|
| 82 | certain DWARF-related problems. In order to overcome this difficulty, |
---|
| 83 | a feature has been added to dwarfout.c (enabled by the -fverbose-asm |
---|
| 84 | option) which causes additional comments to be placed into the assembly |
---|
| 85 | language output file, out to the right-hand side of most bits of DWARF |
---|
| 86 | material. The comments indicate (far more clearly that the obscure |
---|
| 87 | DWARF hex codes do) what is actually being encoded in DWARF. Thus, the |
---|
| 88 | -fverbose-asm option can be highly useful for those who must study the |
---|
| 89 | DWARF output from the GNU compilers in detail. |
---|
| 90 | |
---|
| 91 | --------- |
---|
| 92 | |
---|
| 93 | (Footnote: Within this file, the term `Debugging Information Entry' will |
---|
| 94 | be abbreviated as `DIE'.) |
---|
| 95 | |
---|
| 96 | |
---|
| 97 | Release Notes (aka known bugs) |
---|
| 98 | ------------------------------- |
---|
| 99 | |
---|
| 100 | In one very obscure case involving dynamically sized arrays, the DWARF |
---|
| 101 | "location information" for such an array may make it appear that the |
---|
| 102 | array has been totally optimized out of existence, when in fact it |
---|
| 103 | *must* actually exist. (This only happens when you are using *both* -g |
---|
| 104 | *and* -O.) This is due to aggressive dead store elimination in the |
---|
| 105 | compiler, and to the fact that the DECL_RTL expressions associated with |
---|
| 106 | variables are not always updated to correctly reflect the effects of |
---|
| 107 | GCC's aggressive dead store elimination. |
---|
| 108 | |
---|
| 109 | ------------------------------- |
---|
| 110 | |
---|
| 111 | When attempting to set a breakpoint at the "start" of a function compiled |
---|
| 112 | with -g1, the debugger currently has no way of knowing exactly where the |
---|
| 113 | end of the prologue code for the function is. Thus, for most targets, |
---|
| 114 | all the debugger can do is to set the breakpoint at the AT_low_pc address |
---|
| 115 | for the function. But if you stop there and then try to look at one or |
---|
| 116 | more of the formal parameter values, they may not have been "homed" yet, |
---|
| 117 | so you may get inaccurate answers (or perhaps even addressing errors). |
---|
| 118 | |
---|
| 119 | Some people may consider this simply a non-feature, but I consider it a |
---|
| 120 | bug, and I hope to provide some some GNU-specific attributes (on function |
---|
| 121 | DIEs) which will specify the address of the end of the prologue and the |
---|
| 122 | address of the beginning of the epilogue in a future release. |
---|
| 123 | |
---|
| 124 | ------------------------------- |
---|
| 125 | |
---|
| 126 | It is believed at this time that old bugs relating to the AT_bit_offset |
---|
| 127 | values for bit-fields have been fixed. |
---|
| 128 | |
---|
| 129 | There may still be some very obscure bugs relating to the DWARF description |
---|
| 130 | of type `long long' bit-fields for target machines (e.g. 80x86 machines) |
---|
| 131 | where the alignment of type `long long' data objects is different from |
---|
| 132 | (and less than) the size of a type `long long' data object. |
---|
| 133 | |
---|
| 134 | Please report any problems with the DWARF description of bit-fields as you |
---|
| 135 | would any other GCC bug. (Procedures for bug reporting are given in the |
---|
| 136 | GNU C compiler manual.) |
---|
| 137 | |
---|
| 138 | -------------------------------- |
---|
| 139 | |
---|
| 140 | At this time, GCC does not know how to handle the GNU C "nested functions" |
---|
| 141 | extension. (See the GCC manual for more info on this extension to ANSI C.) |
---|
| 142 | |
---|
| 143 | -------------------------------- |
---|
| 144 | |
---|
| 145 | The GNU compilers now represent inline functions (and inlined instances |
---|
| 146 | thereof) in exactly the manner described by the current DWARF version 2 |
---|
| 147 | (draft) specification. The version 1 specification for handling inline |
---|
| 148 | functions (and inlined instances) was known to be brain-damaged (by the |
---|
| 149 | PLSIG) when the version 1 spec was finalized, but it was simply too late |
---|
| 150 | in the cycle to get it removed before the version 1 spec was formally |
---|
| 151 | released to the public (by UI). |
---|
| 152 | |
---|
| 153 | -------------------------------- |
---|
| 154 | |
---|
| 155 | At this time, GCC does not generate the kind of really precise information |
---|
| 156 | about the exact declared types of entities with signed integral types which |
---|
| 157 | is required by the current DWARF draft specification. |
---|
| 158 | |
---|
| 159 | Specifically, the current DWARF draft specification seems to require that |
---|
| 160 | the type of an non-unsigned integral bit-field member of a struct or union |
---|
| 161 | type be represented as either a "signed" type or as a "plain" type, |
---|
| 162 | depending upon the the exact set of keywords that were used in the |
---|
| 163 | type specification for the given bit-field member. It was felt (by the |
---|
| 164 | UI/PLSIG) that this distinction between "plain" and "signed" integral types |
---|
| 165 | could have some significance (in the case of bit-fields) because ANSI C |
---|
| 166 | does not constrain the signedness of a plain bit-field, whereas it does |
---|
| 167 | constrain the signedness of an explicitly "signed" bit-field. For this |
---|
| 168 | reason, the current DWARF specification calls for compilers to produce |
---|
| 169 | type information (for *all* integral typed entities... not just bit-fields) |
---|
| 170 | which explicitly indicates the signedness of the relevant type to be |
---|
| 171 | "signed" or "plain" or "unsigned". |
---|
| 172 | |
---|
| 173 | Unfortunately, the GNU DWARF implementation is currently incapable of making |
---|
| 174 | such distinctions. |
---|
| 175 | |
---|
| 176 | -------------------------------- |
---|
| 177 | |
---|
| 178 | |
---|
| 179 | Known Interoperability Problems |
---|
| 180 | ------------------------------- |
---|
| 181 | |
---|
| 182 | Although the GNU implementation of DWARF conforms (for the most part) with |
---|
| 183 | the current UI/PLSIG DWARF version 1 specification (with many compatible |
---|
| 184 | version 2 features added in as "vendor specific extensions" just for good |
---|
| 185 | measure) there are a few known cases where GCC's DWARF output can cause |
---|
| 186 | some confusion for "classic" (pre version 1) DWARF consumers such as the |
---|
| 187 | System V Release 4 SDB debugger. These cases are described in this section. |
---|
| 188 | |
---|
| 189 | -------------------------------- |
---|
| 190 | |
---|
| 191 | The DWARF version 1 specification includes the fundamental type codes |
---|
| 192 | FT_ext_prec_float, FT_complex, FT_dbl_prec_complex, and FT_ext_prec_complex. |
---|
| 193 | Since GNU C is only a C compiler (and since C doesn't provide any "complex" |
---|
| 194 | data types) the only one of these fundamental type codes which GCC ever |
---|
| 195 | generates is FT_ext_prec_float. This fundamental type code is generated |
---|
| 196 | by GCC for the `long double' data type. Unfortunately, due to an apparent |
---|
| 197 | bug in the SVR4 SDB debugger, SDB can become very confused wherever any |
---|
| 198 | attempt is made to print a variable, parameter, or field whose type was |
---|
| 199 | given in terms of FT_ext_prec_float. |
---|
| 200 | |
---|
| 201 | (Actually, SVR4 SDB fails to understand *any* of the four fundamental type |
---|
| 202 | codes mentioned here. This will fact will cause additional problems when |
---|
| 203 | there is a GNU FORTRAN front-end.) |
---|
| 204 | |
---|
| 205 | -------------------------------- |
---|
| 206 | |
---|
| 207 | In general, it appears that SVR4 SDB is not able to effectively ignore |
---|
| 208 | fundamental type codes in the "implementation defined" range. This can |
---|
| 209 | cause problems when a program being debugged uses the `long long' data |
---|
| 210 | type (or the signed or unsigned varieties thereof) because these types |
---|
| 211 | are not defined by ANSI C, and thus, GCC must use its own private fundamental |
---|
| 212 | type codes (from the implementation-defined range) to represent these types. |
---|
| 213 | |
---|
| 214 | -------------------------------- |
---|
| 215 | |
---|
| 216 | |
---|
| 217 | General GNU DWARF extensions |
---|
| 218 | ---------------------------- |
---|
| 219 | |
---|
| 220 | In the current DWARF version 1 specification, no mechanism is specified by |
---|
| 221 | which accurate information about executable code from include files can be |
---|
| 222 | properly (and fully) described. (The DWARF version 2 specification *does* |
---|
| 223 | specify such a mechanism, but it is about 10 times more complicated than |
---|
| 224 | it needs to be so I'm not terribly anxious to try to implement it right |
---|
| 225 | away.) |
---|
| 226 | |
---|
| 227 | In the GNU implementation of DWARF version 1, a fully downward-compatible |
---|
| 228 | extension has been implemented which permits the GNU compilers to specify |
---|
| 229 | which executable lines come from which files. This extension places |
---|
| 230 | additional information (about source file names) in GNU-specific sections |
---|
| 231 | (which should be totally ignored by all non-GNU DWARF consumers) so that |
---|
| 232 | this extended information can be provided (to GNU DWARF consumers) in a way |
---|
| 233 | which is totally transparent (and invisible) to non-GNU DWARF consumers |
---|
| 234 | (e.g. the SVR4 SDB debugger). The additional information is placed *only* |
---|
| 235 | in specialized GNU-specific sections, where it should never even be seen |
---|
| 236 | by non-GNU DWARF consumers. |
---|
| 237 | |
---|
| 238 | To understand this GNU DWARF extension, imagine that the sequence of entries |
---|
| 239 | in the .lines section is broken up into several subsections. Each contiguous |
---|
| 240 | sequence of .line entries which relates to a sequence of lines (or statements) |
---|
| 241 | from one particular file (either a `base' file or an `include' file) could |
---|
| 242 | be called a `line entries chunk' (LEC). |
---|
| 243 | |
---|
| 244 | For each LEC there is one entry in the .debug_srcinfo section. |
---|
| 245 | |
---|
| 246 | Each normal entry in the .debug_srcinfo section consists of two 4-byte |
---|
| 247 | words of data as follows: |
---|
| 248 | |
---|
| 249 | (1) The starting address (relative to the entire .line section) |
---|
| 250 | of the first .line entry in the relevant LEC. |
---|
| 251 | |
---|
| 252 | (2) The starting address (relative to the entire .debug_sfnames |
---|
| 253 | section) of a NUL terminated string representing the |
---|
| 254 | relevant filename. (This filename name be either a |
---|
| 255 | relative or an absolute filename, depending upon how the |
---|
| 256 | given source file was located during compilation.) |
---|
| 257 | |
---|
| 258 | Obviously, each .debug_srcinfo entry allows you to find the relevant filename, |
---|
| 259 | and it also points you to the first .line entry that was generated as a result |
---|
| 260 | of having compiled a given source line from the given source file. |
---|
| 261 | |
---|
| 262 | Each subsequent .line entry should also be assumed to have been produced |
---|
| 263 | as a result of compiling yet more lines from the same file. The end of |
---|
| 264 | any given LEC is easily found by looking at the first 4-byte pointer in |
---|
| 265 | the *next* .debug_srcinfo entry. That next .debug_srcinfo entry points |
---|
| 266 | to a new and different LEC, so the preceding LEC (implicitly) must have |
---|
| 267 | ended with the last .line section entry which occurs at the 2 1/2 words |
---|
| 268 | just before the address given in the first pointer of the new .debug_srcinfo |
---|
| 269 | entry. |
---|
| 270 | |
---|
| 271 | The following picture may help to clarify this feature. Let's assume that |
---|
| 272 | `LE' stands for `.line entry'. Also, assume that `* 'stands for a pointer. |
---|
| 273 | |
---|
| 274 | |
---|
| 275 | .line section .debug_srcinfo section .debug_sfnames section |
---|
| 276 | ---------------------------------------------------------------- |
---|
| 277 | |
---|
| 278 | LE <---------------------- * |
---|
| 279 | LE * -----------------> "foobar.c" <--- |
---|
| 280 | LE | |
---|
| 281 | LE | |
---|
| 282 | LE <---------------------- * | |
---|
| 283 | LE * -----------------> "foobar.h" <| | |
---|
| 284 | LE | | |
---|
| 285 | LE | | |
---|
| 286 | LE <---------------------- * | | |
---|
| 287 | LE * -----------------> "inner.h" | | |
---|
| 288 | LE | | |
---|
| 289 | LE <---------------------- * | | |
---|
| 290 | LE * ------------------------------- | |
---|
| 291 | LE | |
---|
| 292 | LE | |
---|
| 293 | LE | |
---|
| 294 | LE | |
---|
| 295 | LE <---------------------- * | |
---|
| 296 | LE * ----------------------------------- |
---|
| 297 | LE |
---|
| 298 | LE |
---|
| 299 | LE |
---|
| 300 | |
---|
| 301 | In effect, each entry in the .debug_srcinfo section points to *both* a |
---|
| 302 | filename (in the .debug_sfnames section) and to the start of a block of |
---|
| 303 | consecutive LEs (in the .line section). |
---|
| 304 | |
---|
| 305 | Note that just like in the .line section, there are specialized first and |
---|
| 306 | last entries in the .debug_srcinfo section for each object file. These |
---|
| 307 | special first and last entries for the .debug_srcinfo section are very |
---|
| 308 | different from the normal .debug_srcinfo section entries. They provide |
---|
| 309 | additional information which may be helpful to a debugger when it is |
---|
| 310 | interpreting the data in the .debug_srcinfo, .debug_sfnames, and .line |
---|
| 311 | sections. |
---|
| 312 | |
---|
| 313 | The first entry in the .debug_srcinfo section for each compilation unit |
---|
| 314 | consists of five 4-byte words of data. The contents of these five words |
---|
| 315 | should be interpreted (by debuggers) as follows: |
---|
| 316 | |
---|
| 317 | (1) The starting address (relative to the entire .line section) |
---|
| 318 | of the .line section for this compilation unit. |
---|
| 319 | |
---|
| 320 | (2) The starting address (relative to the entire .debug_sfnames |
---|
| 321 | section) of the .debug_sfnames section for this compilation |
---|
| 322 | unit. |
---|
| 323 | |
---|
| 324 | (3) The starting address (in the execution virtual address space) |
---|
| 325 | of the .text section for this compilation unit. |
---|
| 326 | |
---|
| 327 | (4) The ending address plus one (in the execution virtual address |
---|
| 328 | space) of the .text section for this compilation unit. |
---|
| 329 | |
---|
| 330 | (5) The date/time (in seconds since midnight 1/1/70) at which the |
---|
| 331 | compilation of this compilation unit occurred. This value |
---|
| 332 | should be interpreted as an unsigned quantity because gcc |
---|
| 333 | might be configured to generate a default value of 0xffffffff |
---|
| 334 | in this field (in cases where it is desired to have object |
---|
| 335 | files created at different times from identical source files |
---|
| 336 | be byte-for-byte identical). By default, these timestamps |
---|
| 337 | are *not* generated by dwarfout.c (so that object files |
---|
| 338 | compiled at different times will be byte-for-byte identical). |
---|
| 339 | If you wish to enable this "timestamp" feature however, you |
---|
| 340 | can simply place a #define for the symbol `DWARF_TIMESTAMPS' |
---|
| 341 | in your target configuration file and then rebuild the GNU |
---|
| 342 | compiler(s). |
---|
| 343 | |
---|
| 344 | Note that the first string placed into the .debug_sfnames section for each |
---|
| 345 | compilation unit is the name of the directory in which compilation occurred. |
---|
| 346 | This string ends with a `/' (to help indicate that it is the pathname of a |
---|
| 347 | directory). Thus, the second word of each specialized initial .debug_srcinfo |
---|
| 348 | entry for each compilation unit may be used as a pointer to the (string) |
---|
| 349 | name of the compilation directory, and that string may in turn be used to |
---|
| 350 | "absolutize" any relative pathnames which may appear later on in the |
---|
| 351 | .debug_sfnames section entries for the same compilation unit. |
---|
| 352 | |
---|
| 353 | The fifth and last word of each specialized starting entry for a compilation |
---|
| 354 | unit in the .debug_srcinfo section may (depending upon your configuration) |
---|
| 355 | indicate the date/time of compilation, and this may be used (by a debugger) |
---|
| 356 | to determine if any of the source files which contributed code to this |
---|
| 357 | compilation unit are newer than the object code for the compilation unit |
---|
| 358 | itself. If so, the debugger may wish to print an "out-of-date" warning |
---|
| 359 | about the compilation unit. |
---|
| 360 | |
---|
| 361 | The .debug_srcinfo section associated with each compilation will also have |
---|
| 362 | a specialized terminating entry. This terminating .debug_srcinfo section |
---|
| 363 | entry will consist of the following two 4-byte words of data: |
---|
| 364 | |
---|
| 365 | (1) The offset, measured from the start of the .line section to |
---|
| 366 | the beginning of the terminating entry for the .line section. |
---|
| 367 | |
---|
| 368 | (2) A word containing the value 0xffffffff. |
---|
| 369 | |
---|
| 370 | -------------------------------- |
---|
| 371 | |
---|
| 372 | In the current DWARF version 1 specification, no mechanism is specified by |
---|
| 373 | which information about macro definitions and un-definitions may be provided |
---|
| 374 | to the DWARF consumer. |
---|
| 375 | |
---|
| 376 | The DWARF version 2 (draft) specification does specify such a mechanism. |
---|
| 377 | That specification was based on the GNU ("vendor specific extension") |
---|
| 378 | which provided some support for macro definitions and un-definitions, |
---|
| 379 | but the "official" DWARF version 2 (draft) specification mechanism for |
---|
| 380 | handling macros and the GNU implementation have diverged somewhat. I |
---|
| 381 | plan to update the GNU implementation to conform to the "official" |
---|
| 382 | DWARF version 2 (draft) specification as soon as I get time to do that. |
---|
| 383 | |
---|
| 384 | Note that in the GNU implementation, additional information about macro |
---|
| 385 | definitions and un-definitions is *only* provided when the -g3 level of |
---|
| 386 | debug-info production is selected. (The default level is -g2 and the |
---|
| 387 | plain old -g option is considered to be identical to -g2.) |
---|
| 388 | |
---|
| 389 | GCC records information about macro definitions and undefinitions primarily |
---|
| 390 | in a section called the .debug_macinfo section. Normal entries in the |
---|
| 391 | .debug_macinfo section consist of the following three parts: |
---|
| 392 | |
---|
| 393 | (1) A special "type" byte. |
---|
| 394 | |
---|
| 395 | (2) A 3-byte line-number/filename-offset field. |
---|
| 396 | |
---|
| 397 | (3) A NUL terminated string. |
---|
| 398 | |
---|
| 399 | The interpretation of the second and third parts is dependent upon the |
---|
| 400 | value of the leading (type) byte. |
---|
| 401 | |
---|
| 402 | The type byte may have one of four values depending upon the type of the |
---|
| 403 | .debug_macinfo entry which follows. The 1-byte MACINFO type codes presently |
---|
| 404 | used, and their meanings are as follows: |
---|
| 405 | |
---|
| 406 | MACINFO_start A base file or an include file starts here. |
---|
| 407 | MACINFO_resume The current base or include file ends here. |
---|
| 408 | MACINFO_define A #define directive occurs here. |
---|
| 409 | MACINFO_undef A #undef directive occur here. |
---|
| 410 | |
---|
| 411 | (Note that the MACINFO_... codes mentioned here are simply symbolic names |
---|
| 412 | for constants which are defined in the GNU dwarf.h file.) |
---|
| 413 | |
---|
| 414 | For MACINFO_define and MACINFO_undef entries, the second (3-byte) field |
---|
| 415 | contains the number of the source line (relative to the start of the current |
---|
| 416 | base source file or the current include files) when the #define or #undef |
---|
| 417 | directive appears. For a MACINFO_define entry, the following string field |
---|
| 418 | contains the name of the macro which is defined, followed by its definition. |
---|
| 419 | Note that the definition is always separated from the name of the macro |
---|
| 420 | by at least one whitespace character. For a MACINFO_undef entry, the |
---|
| 421 | string which follows the 3-byte line number field contains just the name |
---|
| 422 | of the macro which is being undef'ed. |
---|
| 423 | |
---|
| 424 | For a MACINFO_start entry, the 3-byte field following the type byte contains |
---|
| 425 | the offset, relative to the start of the .debug_sfnames section for the |
---|
| 426 | current compilation unit, of a string which names the new source file which |
---|
| 427 | is beginning its inclusion at this point. Following that 3-byte field, |
---|
| 428 | each MACINFO_start entry always contains a zero length NUL terminated |
---|
| 429 | string. |
---|
| 430 | |
---|
| 431 | For a MACINFO_resume entry, the 3-byte field following the type byte contains |
---|
| 432 | the line number WITHIN THE INCLUDING FILE at which the inclusion of the |
---|
| 433 | current file (whose inclusion ends here) was initiated. Following that |
---|
| 434 | 3-byte field, each MACINFO_resume entry always contains a zero length NUL |
---|
| 435 | terminated string. |
---|
| 436 | |
---|
| 437 | Each set of .debug_macinfo entries for each compilation unit is terminated |
---|
| 438 | by a special .debug_macinfo entry consisting of a 4-byte zero value followed |
---|
| 439 | by a single NUL byte. |
---|
| 440 | |
---|
| 441 | -------------------------------- |
---|
| 442 | |
---|
| 443 | In the current DWARF draft specification, no provision is made for providing |
---|
| 444 | a separate level of (limited) debugging information necessary to support |
---|
| 445 | tracebacks (only) through fully-debugged code (e.g. code in system libraries). |
---|
| 446 | |
---|
| 447 | A proposal to define such a level was submitted (by me) to the UI/PLSIG. |
---|
| 448 | This proposal was rejected by the UI/PLSIG for inclusion into the DWARF |
---|
| 449 | version 1 specification for two reasons. First, it was felt (by the PLSIG) |
---|
| 450 | that the issues involved in supporting a "traceback only" subset of DWARF |
---|
| 451 | were not well understood. Second, and perhaps more importantly, the PLSIG |
---|
| 452 | is already having enough trouble agreeing on what it means to be "conforming" |
---|
| 453 | to the DWARF specification, and it was felt that trying to specify multiple |
---|
| 454 | different *levels* of conformance would only complicate our discussions of |
---|
| 455 | this already divisive issue. Nonetheless, the GNU implementation of DWARF |
---|
| 456 | provides an abbreviated "traceback only" level of debug-info production for |
---|
| 457 | use with fully-debugged "system library" code. This level should only be |
---|
| 458 | used for fully debugged system library code, and even then, it should only |
---|
| 459 | be used where there is a very strong need to conserve disk space. This |
---|
| 460 | abbreviated level of debug-info production can be used by specifying the |
---|
| 461 | -g1 option on the compilation command line. |
---|
| 462 | |
---|
| 463 | -------------------------------- |
---|
| 464 | |
---|
| 465 | As mentioned above, the GNU implementation of DWARF currently uses the DWARF |
---|
| 466 | version 2 (draft) approach for inline functions (and inlined instances |
---|
| 467 | thereof). This is used in preference to the version 1 approach because |
---|
| 468 | (quite simply) the version 1 approach is highly brain-damaged and probably |
---|
| 469 | unworkable. |
---|
| 470 | |
---|
| 471 | -------------------------------- |
---|
| 472 | |
---|
| 473 | |
---|
| 474 | GNU DWARF Representation of GNU C Extensions to ANSI C |
---|
| 475 | ------------------------------------------------------ |
---|
| 476 | |
---|
| 477 | The file dwarfout.c has been designed and implemented so as to provide |
---|
| 478 | some reasonable DWARF representation for each and every declarative |
---|
| 479 | construct which is accepted by the GNU C compiler. Since the GNU C |
---|
| 480 | compiler accepts a superset of ANSI C, this means that there are some |
---|
| 481 | cases in which the DWARF information produced by GCC must take some |
---|
| 482 | liberties in improvising DWARF representations for declarations which |
---|
| 483 | are only valid in (extended) GNU C. |
---|
| 484 | |
---|
| 485 | In particular, GNU C provides at least three significant extensions to |
---|
| 486 | ANSI C when it comes to declarations. These are (1) inline functions, |
---|
| 487 | and (2) dynamic arrays, and (3) incomplete enum types. (See the GCC |
---|
| 488 | manual for more information on these GNU extensions to ANSI C.) When |
---|
| 489 | used, these GNU C extensions are represented (in the generated DWARF |
---|
| 490 | output of GCC) in the most natural and intuitively obvious ways. |
---|
| 491 | |
---|
| 492 | In the case of inline functions, the DWARF representation is exactly as |
---|
| 493 | called for in the DWARF version 2 (draft) specification for an identical |
---|
| 494 | function written in C++; i.e. we "reuse" the representation of inline |
---|
| 495 | functions which has been defined for C++ to support this GNU C extension. |
---|
| 496 | |
---|
| 497 | In the case of dynamic arrays, we use the most obvious representational |
---|
| 498 | mechanism available; i.e. an array type in which the upper bound of |
---|
| 499 | some dimension (usually the first and only dimension) is a variable |
---|
| 500 | rather than a constant. (See the DWARF version 1 specification for more |
---|
| 501 | details.) |
---|
| 502 | |
---|
| 503 | In the case of incomplete enum types, such types are represented simply |
---|
| 504 | as TAG_enumeration_type DIEs which DO NOT contain either AT_byte_size |
---|
| 505 | attributes or AT_element_list attributes. |
---|
| 506 | |
---|
| 507 | -------------------------------- |
---|
| 508 | |
---|
| 509 | |
---|
| 510 | Future Directions |
---|
| 511 | ----------------- |
---|
| 512 | |
---|
| 513 | The codes, formats, and other paraphernalia necessary to provide proper |
---|
| 514 | support for symbolic debugging for the C++ language are still being worked |
---|
| 515 | on by the UI/PLSIG. The vast majority of the additions to DWARF which will |
---|
| 516 | be needed to completely support C++ have already been hashed out and agreed |
---|
| 517 | upon, but a few small issues (e.g. anonymous unions, access declarations) |
---|
| 518 | are still being discussed. Also, we in the PLSIG are still discussing |
---|
| 519 | whether or not we need to do anything special for C++ templates. (At this |
---|
| 520 | time it is not yet clear whether we even need to do anything special for |
---|
| 521 | these.) |
---|
| 522 | |
---|
| 523 | Unfortunately, as mentioned above, there are quite a few problems in the |
---|
| 524 | g++ front end itself, and these are currently responsible for severely |
---|
| 525 | restricting the progress which can be made on adding DWARF support |
---|
| 526 | specifically for the g++ front-end. Furthermore, Richard Stallman has |
---|
| 527 | expressed the view that C++ friendships might not be important enough to |
---|
| 528 | describe (in DWARF). This view directly conflicts with both the DWARF |
---|
| 529 | version 1 and version 2 (draft) specifications, so until this small |
---|
| 530 | misunderstanding is cleared up, DWARF support for g++ is unlikely. |
---|
| 531 | |
---|
| 532 | With regard to FORTRAN, the UI/PLSIG has defined what is believed to be a |
---|
| 533 | complete and sufficient set of codes and rules for adequately representing |
---|
| 534 | all of FORTRAN 77, and most of Fortran 90 in DWARF. While some support for |
---|
| 535 | this has been implemented in dwarfout.c, further implementation and testing |
---|
| 536 | will have to await the arrival of the GNU Fortran front-end (which is |
---|
| 537 | currently in early alpha test as of this writing). |
---|
| 538 | |
---|
| 539 | GNU DWARF support for other languages (i.e. Pascal and Modula) is a moot |
---|
| 540 | issue until there are GNU front-ends for these other languages. |
---|
| 541 | |
---|
| 542 | GNU DWARF support for DWARF version 2 will probably not be attempted until |
---|
| 543 | such time as the version 2 specification is finalized. (More work needs |
---|
| 544 | to be done on the version 2 specification to make the new "abbreviations" |
---|
| 545 | feature of version 2 more easily implementable. Until then, it will be |
---|
| 546 | a royal pain the ass to implement version 2 "abbreviations".) For the |
---|
| 547 | time being, version 2 features will be added (in a version 1 compatible |
---|
| 548 | manner) when and where these features seem necessary or extremely desirable. |
---|
| 549 | |
---|
| 550 | As currently defined, DWARF only describes a (binary) language which can |
---|
| 551 | be used to communicate symbolic debugging information from a compiler |
---|
| 552 | through an assembler and a linker, to a debugger. There is no clear |
---|
| 553 | specification of what processing should be (or must be) done by the |
---|
| 554 | assembler and/or the linker. Fortunately, the role of the assembler |
---|
| 555 | is easily inferred (by anyone knowledgeable about assemblers) just by |
---|
| 556 | looking at examples of assembly-level DWARF code. Sadly though, the |
---|
| 557 | allowable (or required) processing steps performed by a linker are |
---|
| 558 | harder to infer and (perhaps) even harder to agree upon. There are |
---|
| 559 | several forms of very useful `post-processing' steps which intelligent |
---|
| 560 | linkers *could* (in theory) perform on object files containing DWARF, |
---|
| 561 | but any and all such link-time transformations are currently both disallowed |
---|
| 562 | and unspecified. |
---|
| 563 | |
---|
| 564 | In particular, possible link-time transformations of DWARF code which could |
---|
| 565 | provide significant benefits include (but are not limited to): |
---|
| 566 | |
---|
| 567 | Commonization of duplicate DIEs obtained from multiple input |
---|
| 568 | (object) files. |
---|
| 569 | |
---|
| 570 | Cross-compilation type checking based upon DWARF type information |
---|
| 571 | for objects and functions. |
---|
| 572 | |
---|
| 573 | Other possible `compacting' transformations designed to save disk |
---|
| 574 | space and to reduce linker & debugger I/O activity. |
---|