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