home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 7 / FreshFishVol7.bin / bbs / gnu / gcc-2.3.3-src.lha / GNU / src / amiga / gcc-2.3.3 / README.DWARF < prev    next >
Text File  |  1994-02-06  |  30KB  |  595 lines
  1. Notes on the GNU Implementation of DWARF Debugging Information
  2. --------------------------------------------------------------
  3. Last Updated: Sun Oct  4 10:04:13 PDT 1992 by rfg@netcom.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 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 archive@ui.org containing the following:
  26.  
  27.         path yourname@your.site
  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, <s.mccarron@ui.org>.
  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 <rfg@netcom.com>.  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. <oldman@dg-rtp.dg.com>.  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. -----------