mingw/info/gdbint/Debugging-GDB.html

   1 <html lang="en">
   2 <head>
   3 <title>GDB Internals</title>
   4 <meta http-equiv="Content-Type" content="text/html">
   5 <meta name="description" content="GDB Internals">
   6 <meta name="generator" content="makeinfo 4.3">
   7 <link href="http://www.gnu.org/software/texinfo/" rel="generator-home">
   8 </head>
   9 <body>
  10 <div class="node">
  11 <p>
  12 Node:<a name="Debugging%20GDB">Debugging GDB</a>,
  13 Up:<a rel="up" accesskey="u" href="Hints.html#Hints">Hints</a>
  14 <hr><br>
  15 </div>
  16
  17 <h3 class="section">Debugging GDB with itself</h3>
  18
  19    <p>If GDB is limping on your machine, this is the preferred way to get it
  20 fully functional.  Be warned that in some ancient Unix systems, like
  21 Ultrix 4.2, a program can't be running in one process while it is being
  22 debugged in another.  Rather than typing the command <kbd>./gdb&nbsp;./gdb</kbd>, which works on Suns and such, you can copy <code>gdb</code> to
  23 <code>gdb2</code> and then type <kbd>./gdb&nbsp;./gdb2</kbd>.
  24
  25    <p>When you run GDB in the GDB source directory, it will read a
  26 <code>.gdbinit</code> file that sets up some simple things to make debugging
  27 gdb easier.  The <code>info</code> command, when executed without a subcommand
  28 in a GDB being debugged by gdb, will pop you back up to the top level
  29 gdb.  See <code>.gdbinit</code> for details.
  30
  31    <p>If you use emacs, you will probably want to do a <code>make TAGS</code> after
  32 you configure your distribution; this will put the machine dependent
  33 routines for your local machine where they will be accessed first by
  34 <kbd>M-.</kbd>
  35
  36    <p>Also, make sure that you've either compiled GDB with your local cc, or
  37 have run <code>fixincludes</code> if you are compiling with gcc.
  38
  39 <h3 class="section">Submitting Patches</h3>
  40
  41    <p>Thanks for thinking of offering your changes back to the community of
  42 GDB users.  In general we like to get well designed enhancements.
  43 Thanks also for checking in advance about the best way to transfer the
  44 changes.
  45
  46    <p>The GDB maintainers will only install "cleanly designed" patches.
  47 This manual summarizes what we believe to be clean design for GDB.
  48
  49    <p>If the maintainers don't have time to put the patch in when it arrives,
  50 or if there is any question about a patch, it goes into a large queue
  51 with everyone else's patches and bug reports.
  52
  53    <p>The legal issue is that to incorporate substantial changes requires a
  54 copyright assignment from you and/or your employer, granting ownership
  55 of the changes to the Free Software Foundation.  You can get the
  56 standard documents for doing this by sending mail to <code>gnu@gnu.org</code>
  57 and asking for it.  We recommend that people write in "All programs
  58 owned by the Free Software Foundation" as "NAME OF PROGRAM", so that
  59 changes in many programs (not just GDB, but GAS, Emacs, GCC,
  60 etc) can be
  61 contributed with only one piece of legalese pushed through the
  62 bureaucracy and filed with the FSF.  We can't start merging changes until
  63 this paperwork is received by the FSF (their rules, which we follow
  64 since we maintain it for them).
  65
  66    <p>Technically, the easiest way to receive changes is to receive each
  67 feature as a small context diff or unidiff, suitable for <code>patch</code>.
  68 Each message sent to me should include the changes to C code and
  69 header files for a single feature, plus <code>ChangeLog</code> entries for
  70 each directory where files were modified, and diffs for any changes
  71 needed to the manuals (<code>gdb/doc/gdb.texinfo</code> or
  72 <code>gdb/doc/gdbint.texinfo</code>).  If there are a lot of changes for a
  73 single feature, they can be split down into multiple messages.
  74
  75    <p>In this way, if we read and like the feature, we can add it to the
  76 sources with a single patch command, do some testing, and check it in.
  77 If you leave out the <code>ChangeLog</code>, we have to write one.  If you leave
  78 out the doc, we have to puzzle out what needs documenting.  Etc., etc.
  79
  80    <p>The reason to send each change in a separate message is that we will not
  81 install some of the changes.  They'll be returned to you with questions
  82 or comments.  If we're doing our job correctly, the message back to you
  83 will say what you have to fix in order to make the change acceptable.
  84 The reason to have separate messages for separate features is so that
  85 the acceptable changes can be installed while one or more changes are
  86 being reworked.  If multiple features are sent in a single message, we
  87 tend to not put in the effort to sort out the acceptable changes from
  88 the unacceptable, so none of the features get installed until all are
  89 acceptable.
  90
  91    <p>If this sounds painful or authoritarian, well, it is.  But we get a lot
  92 of bug reports and a lot of patches, and many of them don't get
  93 installed because we don't have the time to finish the job that the bug
  94 reporter or the contributor could have done.  Patches that arrive
  95 complete, working, and well designed, tend to get installed on the day
  96 they arrive.  The others go into a queue and get installed as time
  97 permits, which, since the maintainers have many demands to meet, may not
  98 be for quite some time.
  99
 100    <p>Please send patches directly to
 101 <a href="mailto:gdb-patches@sources.redhat.com">the GDB maintainers</a>.
 102
 103 <h3 class="section">Obsolete Conditionals</h3>
 104
 105    <p>Fragments of old code in GDB sometimes reference or set the following
 106 configuration macros.  They should not be used by new code, and old uses
 107 should be removed as those parts of the debugger are otherwise touched.
 108
 109      <dl>
 110 <dt><code>STACK_END_ADDR</code>
 111      <dd>This macro used to define where the end of the stack appeared, for use
 112 in interpreting core file formats that don't record this address in the
 113 core file itself.  This information is now configured in BFD, and GDB
 114 gets the info portably from there.  The values in GDB's configuration
 115 files should be moved into BFD configuration files (if needed there),
 116 and deleted from all of GDB's config files.
 117
 118      <p>Any <code></code><var>foo</var><code>-xdep.c</code> file that references STACK_END_ADDR
 119 is so old that it has never been converted to use BFD.  Now that's old!
 120
 121      <br><dt><code>PYRAMID_CONTROL_FRAME_DEBUGGING</code>
 122      <dd>pyr-xdep.c
 123 <br><dt><code>PYRAMID_CORE</code>
 124      <dd>pyr-xdep.c
 125 <br><dt><code>PYRAMID_PTRACE</code>
 126      <dd>pyr-xdep.c
 127
 128      <br><dt><code>REG_STACK_SEGMENT</code>
 129      <dd>exec.c
 130
 131    </dl>
 132
 133    </body></html>
 134