home *** CD-ROM | disk | FTP | other *** search
/ Dream 52 / Amiga_Dream_52.iso / Atari / Gnu / gdb36p4s.zoo / README < prev    next >
Text File  |  1989-10-20  |  7KB  |  143 lines
  1. This is GDB, the GNU source-level debugger, presently running under un*x.
  2.  
  3. Before compiling GDB, you must tell GDB what kind of machine you are
  4. running on.  To do this, type `config.gdb machine', where machine is
  5. something like `vax' or `sun2'.  For a list of valid machine types,
  6. type `config.gdb'.
  7.  
  8. Normally config.gdb edits the makefile as necessary.  If you have to
  9. edit the makefile on a standard machine listed in config.gdb this
  10. should be considered a bug and reported as such.
  11.  
  12. Once these files are set up, just `make' will do everything,
  13. producing an executable `gdb' in this directory.
  14.  
  15. If you want a new (current to this release) version of the manual, you
  16. will have to use the gdb.texinfo file provided with this distribution.
  17. The gdb.texinfo file requires the texinfo-format-buffer command from
  18. emacs 18.55 or later.
  19.  
  20. About languages other than C...
  21.  
  22. C++ support has been integrated into gdb.  GDB should work with
  23. FORTRAN programs (if you have problem, please send a bug report), but
  24. I am not aware of anyone who is working on getting it to use the
  25. syntax of any language other than C or C++.  Pascal programs which use
  26. sets, subranges, file variables, or nested functions will not
  27. currently work.
  28.  
  29. About -gg format...
  30.  
  31. Currently GDB version 3.x does *not* support GCC's -gg format.  This
  32. is because it (in theory) has fast enough startup on dbx debugging
  33. format object files that -gg format is unnecessary (and hence
  34. undesirable, since it wastes space and processing power in gcc).  I
  35. would like to hear people's opinions on the amount of time currently
  36. spent in startup; is it fast enough?
  37.  
  38. About remote debugging...
  39.  
  40. The two files remote-multi.shar and remote-sa.m68k.shar contain two
  41. examples of a remote stub to be used with remote.c.  The the -multi
  42. file is a general stub that can probably be running on various
  43. different flavors of unix to allow debugging over a serial line from
  44. one machine to another.  The remote-sa.m68k.shar is designed to run
  45. standalone on a 68k type cpu and communicate properley with the
  46. remote.c stub over a serial line.
  47.  
  48. About reporting bugs...
  49.  
  50. The correct address for reporting bugs found with gdb is
  51. "bug-gdb@prep.ai.mit.edu".  Please send all bugs to that address.
  52.  
  53. About xgdb...
  54.  
  55. xgdb.c was provided to us by the user community; it is not an integral
  56. part of the gdb distribution.  The problem of providing visual
  57. debugging support on top of gdb is peripheral to the GNU project and
  58. (at least right now) we can't afford to put time into it.  So while we
  59. will be happy to incorporate user fixes to xgdb.c, we do not guarantee
  60. that it will work and we will not fix bugs reported in it.  Someone is
  61. working on writing a new XGDB, so improving (e.g. by fixing it so that
  62. it will work, if it doesn't currently) the current one is not worth it.
  63.  
  64. For those intersted in auto display of source and the availability of
  65. an editor while debugging I suggest trying gdb-mode in gnu-emacs.
  66. Comments on this mode are welcome.
  67.  
  68. About the machine-dependent files...
  69.  
  70. m-<machine>.h (param.h is a link to this file).
  71. This file contains macro definitions that express information
  72. about the machine's registers, stack frame format and instructions.
  73.  
  74. <machine>-opcode.h (opcode.h is a link to this file).
  75. <machine>-pinsn.c (pinsn.c is a link to this file).
  76. These files contain the information necessary to print instructions
  77. for your cpu type.
  78.  
  79. <machine>-dep.c (dep.c is a link to this file).
  80. Those routines which provide a low level interface to ptrace and which
  81. tend to be machine-dependent.  (The machine-independent routines are in
  82. `infrun.c' and `inflow.c')
  83.  
  84. About writing code for GDB...
  85.  
  86. We appreciate having users contribute code that is of general use, but
  87. for it to be included in future GDB releases it must be cleanly
  88. written.  We do not want to include changes that will needlessly make future
  89. maintainance difficult.  It is not much harder to do things right, and
  90. in the long term it is worth it to the GNU project, and probably to
  91. you individually as well.
  92.  
  93. Please code according to the GNU coding standards.  If you do not have
  94. a copy, you can request one by sending mail to gnu@prep.ai.mit.edu.
  95.  
  96. Please try to avoid making machine-specific changes to
  97. machine-independent files (i.e. all files except "param.h" and
  98. "dep.c".  "pinsn.c" and "opcode.h" are processor-specific but not
  99. operating system-dependent).  If this is unavoidable, put a hook in
  100. the machine-independent file which calls a (possibly)
  101. machine-dependent macro (for example, the IGNORE_SYMBOL macro can be
  102. used for any symbols which need to be ignored on a specific machine.
  103. Calling IGNORE_SYMBOL in dbxread.c is a lot cleaner than a maze of #if
  104. defined's).  The machine-independent code should do whatever "most"
  105. machines want if the macro is not defined in param.h.  Using #if
  106. defined can sometimes be OK (e.g.  SET_STACK_LIMIT_HUGE) but should be
  107. conditionalized on a specific feature of an operating system (set in
  108. param.h) rather than something like #if defined(vax) or #if
  109. defined(SYSV).
  110.  
  111. It is better to replace entire routines which may be system-specific,
  112. rather than put in a whole bunch of hooks which are probably not going
  113. to be helpful for any purpose other than your changes.  For example,
  114. if you want to modify dbxread.c to deal with DBX debugging symbols
  115. which are in COFF files rather than BSD a.out files, do something
  116. along the lines of a macro GET_NEXT_SYMBOL, which could have
  117. different definitions for COFF and a.out, rather than trying to put
  118. the necessary changes throughout all the code in dbxread.c that
  119. currently assumes BSD format.
  120.  
  121. Please avoid duplicating code.  For example, if something needs to be
  122. changed in read_inferior_memory, it is very painful because there is a
  123. copy in every dep.c file.  The correct way to do this is to put (in
  124. this case) the standard ptrace interfaces in a separate file ptrace.c,
  125. which is used by all systems which have ptrace.  ptrace.c would deal
  126. with variations between systems the same way any system-independent
  127. file would (hooks, #if defined, etc.).
  128.  
  129. About debugging gdb with itself...
  130.  
  131. You probably want to do a "make TAGS" after you configure your
  132. distribution; this will put the machine dependent routines for your
  133. local machine where they will be accessed first by a M-period .
  134.  
  135. Also, make sure that you've compiled gdb with your local cc or taken
  136. appropriate precautions regarding ansification of include files.  See
  137. the Makefile for more information.
  138.  
  139. The "info" command, when executed without a subcommand in a gdb being
  140. debugged by gdb, will pop you back up to the top level gdb.  See
  141. .gdbinit for more details.
  142.  
  143.