mingw/info/gdbint/Coding.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="Coding">Coding</a>,
  13 Next:<a rel="next" accesskey="n" href="Porting-GDB.html#Porting%20GDB">Porting GDB</a>,
  14 Previous:<a rel="previous" accesskey="p" href="Support-Libraries.html#Support%20Libraries">Support Libraries</a>,
  15 Up:<a rel="up" accesskey="u" href="index.html#Top">Top</a>
  16 <hr><br>
  17 </div>
  18
  19 <h2 class="chapter">Coding</h2>
  20
  21    <p>This chapter covers topics that are lower-level than the major
  22 algorithms of GDB.
  23
  24 <h3 class="section">Cleanups</h3>
  25
  26    <p>Cleanups are a structured way to deal with things that need to be done
  27 later.
  28
  29    <p>When your code does something (e.g., <code>xmalloc</code> some memory, or
  30 <code>open</code> a file) that needs to be undone later (e.g., <code>xfree</code>
  31 the memory or <code>close</code> the file), it can make a cleanup.  The
  32 cleanup will be done at some future point: when the command is finished
  33 and control returns to the top level; when an error occurs and the stack
  34 is unwound; or when your code decides it's time to explicitly perform
  35 cleanups.  Alternatively you can elect to discard the cleanups you
  36 created.
  37
  38    <p>Syntax:
  39
  40      <dl>
  41 <dt><code>struct cleanup *</code><var>old_chain</var><code>;</code>
  42      <dd>Declare a variable which will hold a cleanup chain handle.
  43
  44      <br><dt><code></code><var>old_chain</var><code> = make_cleanup (</code><var>function</var><code>, </code><var>arg</var><code>);</code>
  45      <dd>Make a cleanup which will cause <var>function</var> to be called with
  46 <var>arg</var> (a <code>char *</code>) later.  The result, <var>old_chain</var>, is a
  47 handle that can later be passed to <code>do_cleanups</code> or
  48 <code>discard_cleanups</code>.  Unless you are going to call
  49 <code>do_cleanups</code> or <code>discard_cleanups</code>, you can ignore the result
  50 from <code>make_cleanup</code>.
  51
  52      <br><dt><code>do_cleanups (</code><var>old_chain</var><code>);</code>
  53      <dd>Do all cleanups added to the chain since the corresponding
  54 <code>make_cleanup</code> call was made.
  55
  56      <br><dt><code>discard_cleanups (</code><var>old_chain</var><code>);</code>
  57      <dd>Same as <code>do_cleanups</code> except that it just removes the cleanups from
  58 the chain and does not call the specified functions.
  59 </dl>
  60
  61    <p>Cleanups are implemented as a chain.  The handle returned by
  62 <code>make_cleanups</code> includes the cleanup passed to the call and any
  63 later cleanups appended to the chain (but not yet discarded or
  64 performed).  E.g.:
  65
  66 <pre class="example">     make_cleanup (a, 0);
  67      {
  68        struct cleanup *old = make_cleanup (b, 0);
  69        make_cleanup (c, 0)
  70        ...
  71        do_cleanups (old);
  72      }
  73      </pre>
  74
  75 <p>will call <code>c()</code> and <code>b()</code> but will not call <code>a()</code>.  The
  76 cleanup that calls <code>a()</code> will remain in the cleanup chain, and will
  77 be done later unless otherwise discarded.
  78
  79    <p>Your function should explicitly do or discard the cleanups it creates.
  80 Failing to do this leads to non-deterministic behavior since the caller
  81 will arbitrarily do or discard your functions cleanups.  This need leads
  82 to two common cleanup styles.
  83
  84    <p>The first style is try/finally.  Before it exits, your code-block calls
  85 <code>do_cleanups</code> with the old cleanup chain and thus ensures that your
  86 code-block's cleanups are always performed.  For instance, the following
  87 code-segment avoids a memory leak problem (even when <code>error</code> is
  88 called and a forced stack unwind occurs) by ensuring that the
  89 <code>xfree</code> will always be called:
  90
  91 <pre class="example">     struct cleanup *old = make_cleanup (null_cleanup, 0);
  92      data = xmalloc (sizeof blah);
  93      make_cleanup (xfree, data);
  94      ... blah blah ...
  95      do_cleanups (old);
  96      </pre>
  97
  98    <p>The second style is try/except.  Before it exits, your code-block calls
  99 <code>discard_cleanups</code> with the old cleanup chain and thus ensures that
 100 any created cleanups are not performed.  For instance, the following
 101 code segment, ensures that the file will be closed but only if there is
 102 an error:
 103
 104 <pre class="example">     FILE *file = fopen ("afile", "r");
 105      struct cleanup *old = make_cleanup (close_file, file);
 106      ... blah blah ...
 107      discard_cleanups (old);
 108      return file;
 109      </pre>
 110
 111    <p>Some functions, e.g. <code>fputs_filtered()</code> or <code>error()</code>, specify
 112 that they "should not be called when cleanups are not in place".  This
 113 means that any actions you need to reverse in the case of an error or
 114 interruption must be on the cleanup chain before you call these
 115 functions, since they might never return to your code (they
 116 <code>longjmp</code> instead).
 117
 118 <h3 class="section">Wrapping Output Lines</h3>
 119
 120    <p>Output that goes through <code>printf_filtered</code> or <code>fputs_filtered</code>
 121 or <code>fputs_demangled</code> needs only to have calls to <code>wrap_here</code>
 122 added in places that would be good breaking points.  The utility
 123 routines will take care of actually wrapping if the line width is
 124 exceeded.
 125
 126    <p>The argument to <code>wrap_here</code> is an indentation string which is
 127 printed <em>only</em> if the line breaks there.  This argument is saved
 128 away and used later.  It must remain valid until the next call to
 129 <code>wrap_here</code> or until a newline has been printed through the
 130 <code>*_filtered</code> functions.  Don't pass in a local variable and then
 131 return!
 132
 133    <p>It is usually best to call <code>wrap_here</code> after printing a comma or
 134 space.  If you call it before printing a space, make sure that your
 135 indentation properly accounts for the leading space that will print if
 136 the line wraps there.
 137
 138    <p>Any function or set of functions that produce filtered output must
 139 finish by printing a newline, to flush the wrap buffer, before switching
 140 to unfiltered (<code>printf</code>) output.  Symbol reading routines that
 141 print warnings are a good example.
 142
 143 <h3 class="section">GDB Coding Standards</h3>
 144
 145    GDB follows the GNU coding standards, as described in
 146 <code>etc/standards.texi</code>.  This file is also available for anonymous
 147 FTP from GNU archive sites.  GDB takes a strict interpretation
 148 of the standard; in general, when the GNU standard recommends a practice
 149 but does not require it, GDB requires it.
 150
 151    GDB follows an additional set of coding standards specific to
 152 GDB, as described in the following sections.
 153
 154 <h4 class="subsection">ISO-C</h4>
 155
 156    GDB assumes an ISO-C compliant compiler.
 157
 158    GDB does not assume an ISO-C or POSIX compliant C library.
 159
 160 <h4 class="subsection">Memory Management</h4>
 161
 162    GDB does not use the functions <code>malloc</code>, <code>realloc</code>,
 163 <code>calloc</code>, <code>free</code> and <code>asprintf</code>.
 164
 165    GDB uses the functions <code>xmalloc</code>, <code>xrealloc</code> and
 166 <code>xcalloc</code> when allocating memory.  Unlike <code>malloc</code> et.al.
 167 these functions do not return when the memory pool is empty.  Instead,
 168 they unwind the stack using cleanups.  These functions return
 169 <code>NULL</code> when requested to allocate a chunk of memory of size zero.
 170
 171    <p><em>Pragmatics: By using these functions, the need to check every
 172 memory allocation is removed.  These functions provide portable
 173 behavior.</em>
 174
 175    GDB does not use the function <code>free</code>.
 176
 177    GDB uses the function <code>xfree</code> to return memory to the
 178 memory pool.  Consistent with ISO-C, this function ignores a request to
 179 free a <code>NULL</code> pointer.
 180
 181    <p><em>Pragmatics: On some systems </em><code>free</code><em> fails when passed a
 182 </em><code>NULL</code><em> pointer.</em>
 183
 184    GDB can use the non-portable function <code>alloca</code> for the
 185 allocation of small temporary values (such as strings).
 186
 187    <p><em>Pragmatics: This function is very non-portable.  Some systems
 188 restrict the memory being allocated to no more than a few kilobytes.</em>
 189
 190    GDB uses the string function <code>xstrdup</code> and the print
 191 function <code>xasprintf</code>.
 192
 193    <p><em>Pragmatics: </em><code>asprintf</code><em> and </em><code>strdup</code><em> can fail.  Print
 194 functions such as </em><code>sprintf</code><em> are very prone to buffer overflow
 195 errors.</em>
 196
 197 <h4 class="subsection">Compiler Warnings</h4>
 198
 199    <p>With few exceptions, developers should include the configuration option
 200 <code>--enable-gdb-build-warnings=,-Werror</code> when building GDB.
 201 The exceptions are listed in the file <code>gdb/MAINTAINERS</code>.
 202
 203    <p>This option causes GDB (when built using GCC) to be compiled
 204 with a carefully selected list of compiler warning flags.  Any warnings
 205 from those flags being treated as errors.
 206
 207    <p>The current list of warning flags includes:
 208
 209      <dl>
 210 <dt><code>-Wimplicit</code>
 211      <dd>Since GDB coding standard requires all functions to be declared
 212 using a prototype, the flag has the side effect of ensuring that
 213 prototyped functions are always visible with out resorting to
 214 <code>-Wstrict-prototypes</code>.
 215
 216      <br><dt><code>-Wreturn-type</code>
 217      <dd>Such code often appears to work except on instruction set architectures
 218 that use register windows.
 219
 220      <br><dt><code>-Wcomment</code>
 221      <dd>
 222 <br><dt><code>-Wtrigraphs</code>
 223      <dd>
 224 <br><dt><code>-Wformat</code>
 225      <dd>Since GDB uses the <code>format printf</code> attribute on all
 226 <code>printf</code> like functions this checks not just <code>printf</code> calls
 227 but also calls to functions such as <code>fprintf_unfiltered</code>.
 228
 229      <br><dt><code>-Wparentheses</code>
 230      <dd>This warning includes uses of the assignment operator within an
 231 <code>if</code> statement.
 232
 233      <br><dt><code>-Wpointer-arith</code>
 234      <dd>
 235 <br><dt><code>-Wuninitialized</code>
 236      <dd></dl>
 237
 238    <p><em>Pragmatics: Due to the way that GDB is implemented most
 239 functions have unused parameters.  Consequently the warning
 240 </em><code>-Wunused-parameter</code><em> is precluded from the list.  The macro
 241 </em><code>ATTRIBUTE_UNUSED</code><em> is not used as it leads to false negatives --
 242 it is not an error to have </em><code>ATTRIBUTE_UNUSED</code><em> on a parameter that
 243 is being used.  The options </em><code>-Wall</code><em> and </em><code>-Wunused</code><em> are also
 244 precluded because they both include </em><code>-Wunused-parameter</code><em>.</em>
 245
 246    <p><em>Pragmatics: GDB has not simply accepted the warnings
 247 enabled by </em><code>-Wall -Werror -W...</code><em>.  Instead it is selecting warnings
 248 when and where their benefits can be demonstrated.</em>
 249
 250 <h4 class="subsection">Formatting</h4>
 251
 252    <p>The standard GNU recommendations for formatting must be followed
 253 strictly.
 254
 255    <p>A function declaration should not have its name in column zero.  A
 256 function definition should have its name in column zero.
 257
 258 <pre class="example">     /* Declaration */
 259      static void foo (void);
 260      /* Definition */
 261      void
 262      foo (void)
 263      {
 264      }
 265      </pre>
 266
 267    <p><em>Pragmatics: This simplifies scripting.  Function definitions can
 268 be found using </em><code>^function-name</code><em>.</em>
 269
 270    <p>There must be a space between a function or macro name and the opening
 271 parenthesis of its argument list (except for macro definitions, as
 272 required by C).  There must not be a space after an open paren/bracket
 273 or before a close paren/bracket.
 274
 275    <p>While additional whitespace is generally helpful for reading, do not use
 276 more than one blank line to separate blocks, and avoid adding whitespace
 277 after the end of a program line (as of 1/99, some 600 lines had
 278 whitespace after the semicolon).  Excess whitespace causes difficulties
 279 for <code>diff</code> and <code>patch</code> utilities.
 280
 281    <p>Pointers are declared using the traditional K&amp;R C style:
 282
 283 <pre class="example">     void *foo;
 284      </pre>
 285
 286 <p>and not:
 287
 288 <pre class="example">     void * foo;
 289      void* foo;
 290      </pre>
 291
 292 <h4 class="subsection">Comments</h4>
 293
 294    <p>The standard GNU requirements on comments must be followed strictly.
 295
 296    <p>Block comments must appear in the following form, with no <code>/*</code>- or
 297 <code>*/</code>-only lines, and no leading <code>*</code>:
 298
 299 <pre class="example">     /* Wait for control to return from inferior to debugger.  If inferior
 300         gets a signal, we may decide to start it up again instead of
 301         returning.  That is why there is a loop in this function.  When
 302         this function actually returns it means the inferior should be left
 303         stopped and GDB should read more commands.  */
 304      </pre>
 305
 306    <p>(Note that this format is encouraged by Emacs; tabbing for a multi-line
 307 comment works correctly, and <kbd>M-q</kbd> fills the block consistently.)
 308
 309    <p>Put a blank line between the block comments preceding function or
 310 variable definitions, and the definition itself.
 311
 312    <p>In general, put function-body comments on lines by themselves, rather
 313 than trying to fit them into the 20 characters left at the end of a
 314 line, since either the comment or the code will inevitably get longer
 315 than will fit, and then somebody will have to move it anyhow.
 316
 317 <h4 class="subsection">C Usage</h4>
 318
 319    <p>Code must not depend on the sizes of C data types, the format of the
 320 host's floating point numbers, the alignment of anything, or the order
 321 of evaluation of expressions.
 322
 323    <p>Use functions freely.  There are only a handful of compute-bound areas
 324 in GDB that might be affected by the overhead of a function
 325 call, mainly in symbol reading.  Most of GDB's performance is
 326 limited by the target interface (whether serial line or system call).
 327
 328    <p>However, use functions with moderation.  A thousand one-line functions
 329 are just as hard to understand as a single thousand-line function.
 330
 331    <p><em>Macros are bad, M'kay.</em>
 332 (But if you have to use a macro, make sure that the macro arguments are
 333 protected with parentheses.)
 334
 335    <p>Declarations like <code>struct foo *</code> should be used in preference to
 336 declarations like <code>typedef struct foo { ... } *foo_ptr</code>.
 337
 338 <h4 class="subsection">Function Prototypes</h4>
 339
 340    <p>Prototypes must be used when both <em>declaring</em> and <em>defining</em>
 341 a function.  Prototypes for GDB functions must include both the
 342 argument type and name, with the name matching that used in the actual
 343 function definition.
 344
 345    <p>All external functions should have a declaration in a header file that
 346 callers include, except for <code>_initialize_*</code> functions, which must
 347 be external so that <code>init.c</code> construction works, but shouldn't be
 348 visible to random source files.
 349
 350    <p>Where a source file needs a forward declaration of a static function,
 351 that declaration must appear in a block near the top of the source file.
 352
 353 <h4 class="subsection">Internal Error Recovery</h4>
 354
 355    <p>During its execution, GDB can encounter two types of errors.
 356 User errors and internal errors.  User errors include not only a user
 357 entering an incorrect command but also problems arising from corrupt
 358 object files and system errors when interacting with the target.
 359 Internal errors include situtations where GDB has detected, at
 360 run time, a corrupt or erroneous situtation.
 361
 362    <p>When reporting an internal error, GDB uses
 363 <code>internal_error</code> and <code>gdb_assert</code>.
 364
 365    GDB must not call <code>abort</code> or <code>assert</code>.
 366
 367    <p><em>Pragmatics: There is no </em><code>internal_warning</code><em> function.  Either
 368 the code detected a user error, recovered from it and issued a
 369 </em><code>warning</code><em> or the code failed to correctly recover from the user
 370 error and issued an </em><code>internal_error</code><em>.</em>
 371
 372 <h4 class="subsection">File Names</h4>
 373
 374    <p>Any file used when building the core of GDB must be in lower
 375 case. Any file used when building the core of GDB must be 8.3
 376 unique.  These requirements apply to both source and generated files.
 377
 378    <p><em>Pragmatics: The core of GDB must be buildable on many
 379 platforms including DJGPP and MacOS/HFS.  Every time an unfriendly file
 380 is introduced to the build process both </em><code>Makefile.in</code><em> and
 381 </em><code>configure.in</code><em> need to be modified accordingly.  Compare the
 382 convoluted conversion process needed to transform </em><code>COPYING</code><em> into
 383 </em><code>copying.c</code><em> with the conversion needed to transform
 384 </em><code>version.in</code><em> into </em><code>version.c</code><em>.</em>
 385
 386    <p>Any file non 8.3 compliant file (that is not used when building the core
 387 of GDB) must be added to <code>gdb/config/djgpp/fnchange.lst</code>.
 388
 389    <p><em>Pragmatics: This is clearly a compromise.</em>
 390
 391    <p>When GDB has a local version of a system header file (ex
 392 <code>string.h</code>) the file name based on the POSIX header prefixed with
 393 <code>gdb_</code> (<code>gdb_string.h</code>).
 394
 395    <p>For other files <code>-</code> is used as the separator.
 396
 397 <h4 class="subsection">Include Files</h4>
 398
 399    <p>All <code>.c</code> files should include <code>defs.h</code> first.
 400
 401    <p>All <code>.c</code> files should explicitly include the headers for any
 402 declarations they refer to.  They should not rely on files being
 403 included indirectly.
 404
 405    <p>With the exception of the global definitions supplied by <code>defs.h</code>,
 406 a header file should explictily include the header declaring any
 407 <code>typedefs</code> et.al. it refers to.
 408
 409    <p><code>extern</code> declarations should never appear in <code>.c</code> files.
 410
 411    <p>All include files should be wrapped in:
 412
 413 <pre class="example">     #ifndef INCLUDE_FILE_NAME_H
 414      #define INCLUDE_FILE_NAME_H
 415      header body
 416      #endif
 417      </pre>
 418
 419 <h4 class="subsection">Clean Design and Portable Implementation</h4>
 420
 421    <p>In addition to getting the syntax right, there's the little question of
 422 semantics.  Some things are done in certain ways in GDB because long
 423 experience has shown that the more obvious ways caused various kinds of
 424 trouble.
 425
 426    <p>You can't assume the byte order of anything that comes from a target
 427 (including <var>value</var>s, object files, and instructions).  Such things
 428 must be byte-swapped using <code>SWAP_TARGET_AND_HOST</code> in
 429 GDB, or one of the swap routines defined in <code>bfd.h</code>,
 430 such as <code>bfd_get_32</code>.
 431
 432    <p>You can't assume that you know what interface is being used to talk to
 433 the target system.  All references to the target must go through the
 434 current <code>target_ops</code> vector.
 435
 436    <p>You can't assume that the host and target machines are the same machine
 437 (except in the "native" support modules).  In particular, you can't
 438 assume that the target machine's header files will be available on the
 439 host machine.  Target code must bring along its own header files -
 440 written from scratch or explicitly donated by their owner, to avoid
 441 copyright problems.
 442
 443    <p>Insertion of new <code>#ifdef</code>'s will be frowned upon.  It's much better
 444 to write the code portably than to conditionalize it for various
 445 systems.
 446
 447    <p>New <code>#ifdef</code>'s which test for specific compilers or manufacturers
 448 or operating systems are unacceptable.  All <code>#ifdef</code>'s should test
 449 for features.  The information about which configurations contain which
 450 features should be segregated into the configuration files.  Experience
 451 has proven far too often that a feature unique to one particular system
 452 often creeps into other systems; and that a conditional based on some
 453 predefined macro for your current system will become worthless over
 454 time, as new versions of your system come out that behave differently
 455 with regard to this feature.
 456
 457    <p>Adding code that handles specific architectures, operating systems,
 458 target interfaces, or hosts, is not acceptable in generic code.
 459
 460    <p>One particularly notorious area where system dependencies tend to
 461 creep in is handling of file names.  The mainline GDB code
 462 assumes Posix semantics of file names: absolute file names begin with
 463 a forward slash <code>/</code>, slashes are used to separate leading
 464 directories, case-sensitive file names.  These assumptions are not
 465 necessarily true on non-Posix systems such as MS-Windows.  To avoid
 466 system-dependent code where you need to take apart or construct a file
 467 name, use the following portable macros:
 468
 469      <dl>
 470 <dt><code>HAVE_DOS_BASED_FILE_SYSTEM</code>
 471      <dd>This preprocessing symbol is defined to a non-zero value on hosts
 472 whose filesystems belong to the MS-DOS/MS-Windows family.  Use this
 473 symbol to write conditional code which should only be compiled for
 474 such hosts.
 475
 476      <br><dt><code>IS_DIR_SEPARATOR (</code><var>c</var><code>)</code>
 477      <dd>Evaluates to a non-zero value if <var>c</var> is a directory separator
 478 character.  On Unix and GNU/Linux systems, only a slash <code>/</code> is
 479 such a character, but on Windows, both <code>/</code> and <code>\</code> will
 480 pass.
 481
 482      <br><dt><code>IS_ABSOLUTE_PATH (</code><var>file</var><code>)</code>
 483      <dd>Evaluates to a non-zero value if <var>file</var> is an absolute file name.
 484 For Unix and GNU/Linux hosts, a name which begins with a slash
 485 <code>/</code> is absolute.  On DOS and Windows, <code>d:/foo</code> and
 486 <code>x:\bar</code> are also absolute file names.
 487
 488      <br><dt><code>FILENAME_CMP (</code><var>f1</var><code>, </code><var>f2</var><code>)</code>
 489      <dd>Calls a function which compares file names <var>f1</var> and <var>f2</var> as
 490 appropriate for the underlying host filesystem.  For Posix systems,
 491 this simply calls <code>strcmp</code>; on case-insensitive filesystems it
 492 will call <code>strcasecmp</code> instead.
 493
 494      <br><dt><code>DIRNAME_SEPARATOR</code>
 495      <dd>Evaluates to a character which separates directories in
 496 <code>PATH</code>-style lists, typically held in environment variables.
 497 This character is <code>:</code> on Unix, <code>;</code> on DOS and Windows.
 498
 499      <br><dt><code>SLASH_STRING</code>
 500      <dd>This evaluates to a constant string you should use to produce an
 501 absolute filename from leading directories and the file's basename.
 502 <code>SLASH_STRING</code> is <code>"/"</code> on most systems, but might be
 503 <code>"\\"</code> for some Windows-based ports.
 504 </dl>
 505
 506    <p>In addition to using these macros, be sure to use portable library
 507 functions whenever possible.  For example, to extract a directory or a
 508 basename part from a file name, use the <code>dirname</code> and
 509 <code>basename</code> library functions (available in <code>libiberty</code> for
 510 platforms which don't provide them), instead of searching for a slash
 511 with <code>strrchr</code>.
 512
 513    <p>Another way to generalize GDB along a particular interface is with an
 514 attribute struct.  For example, GDB has been generalized to handle
 515 multiple kinds of remote interfaces--not by <code>#ifdef</code>s everywhere, but
 516 by defining the <code>target_ops</code> structure and having a current target (as
 517 well as a stack of targets below it, for memory references).  Whenever
 518 something needs to be done that depends on which remote interface we are
 519 using, a flag in the current target_ops structure is tested (e.g.,
 520 <code>target_has_stack</code>), or a function is called through a pointer in the
 521 current target_ops structure.  In this way, when a new remote interface
 522 is added, only one module needs to be touched--the one that actually
 523 implements the new remote interface.  Other examples of
 524 attribute-structs are BFD access to multiple kinds of object file
 525 formats, or GDB's access to multiple source languages.
 526
 527    <p>Please avoid duplicating code.  For example, in GDB 3.x all
 528 the code interfacing between <code>ptrace</code> and the rest of
 529 GDB was duplicated in <code>*-dep.c</code>, and so changing
 530 something was very painful.  In GDB 4.x, these have all been
 531 consolidated into <code>infptrace.c</code>.  <code>infptrace.c</code> can deal
 532 with variations between systems the same way any system-independent
 533 file would (hooks, <code>#if defined</code>, etc.), and machines which are
 534 radically different don't need to use <code>infptrace.c</code> at all.
 535
 536    <p>All debugging code must be controllable using the <code>set debug
 537 </code><var>module</var><code></code> command.  Do not use <code>printf</code> to print trace
 538 messages.  Use <code>fprintf_unfiltered(gdb_stdlog, ...</code>.  Do not use
 539 <code>#ifdef DEBUG</code>.
 540
 541    </body></html>
 542