Initial creation of sourceware repository

1 files changed, 1338 insertions, 0 deletions

diff --git a/gdb/doc/gdbint.info-2 b/gdb/doc/gdbint.info-2
new file mode 100644
index 0000000..612cf0f
--- /dev/null
+++ b/gdb/doc/gdbint.info-2
@@ -0,0 +1,1338 @@
+This is Info file gdbint.info, produced by Makeinfo version 1.68 from
+the input file ./gdbint.texinfo.
+
+START-INFO-DIR-ENTRY
+* Gdb-Internals: (gdbint).	The GNU debugger's internals.
+END-INFO-DIR-ENTRY
+
+   This file documents the internals of the GNU debugger GDB.
+
+   Copyright 1990-1999 Free Software Foundation, Inc.  Contributed by
+Cygnus Solutions.  Written by John Gilmore.  Second Edition by Stan
+Shebs.
+
+   Permission is granted to make and distribute verbatim copies of this
+manual provided the copyright notice and this permission notice are
+preserved on all copies.
+
+   Permission is granted to copy or distribute modified versions of this
+manual under the terms of the GPL (for which purpose this text may be
+regarded as a program in the language TeX).
+
+
+File: gdbint.info,  Node: Target Architecture Definition,  Next: Target Vector Definition,  Prev: Host Definition,  Up: Top
+
+Target Architecture Definition
+******************************
+
+   GDB's target architecture defines what sort of machine-language
+programs GDB can work with, and how it works with them.
+
+   At present, the target architecture definition consists of a number
+of C macros.
+
+Registers and Memory
+====================
+
+   GDB's model of the target machine is rather simple.  GDB assumes the
+machine includes a bank of registers and a block of memory.  Each
+register may have a different size.
+
+   GDB does not have a magical way to match up with the compiler's idea
+of which registers are which; however, it is critical that they do
+match up accurately.  The only way to make this work is to get accurate
+information about the order that the compiler uses, and to reflect that
+in the `REGISTER_NAME' and related macros.
+
+   GDB can handle big-endian, little-endian, and bi-endian
+architectures.
+
+Frame Interpretation
+====================
+
+Inferior Call Setup
+===================
+
+Compiler Characteristics
+========================
+
+Target Conditionals
+===================
+
+   This section describes the macros that you can use to define the
+target machine.
+
+`ADDITIONAL_OPTIONS'
+
+`ADDITIONAL_OPTION_CASES'
+
+`ADDITIONAL_OPTION_HANDLER'
+
+`ADDITIONAL_OPTION_HELP'
+     These are a set of macros that allow the addition of additional
+     command line options to GDB.  They are currently used only for the
+     unsupported i960 Nindy target, and should not be used in any other
+     configuration.
+
+`ADDR_BITS_REMOVE (addr)'
+     If a raw machine address includes any bits that are not really
+     part of the address, then define this macro to expand into an
+     expression that zeros those bits in ADDR.  For example, the two
+     low-order bits of a Motorola 88K address may be used by some
+     kernels for their own purposes, since addresses must always be
+     4-byte aligned, and so are of no use for addressing.  Those bits
+     should be filtered out with an expression such as `((addr) & ~3)'.
+
+`BEFORE_MAIN_LOOP_HOOK'
+     Define this to expand into any code that you want to execute
+     before the main loop starts.  Although this is not, strictly
+     speaking, a target conditional, that is how it is currently being
+     used.  Note that if a configuration were to define it one way for
+     a host and a different way for the target, GDB will probably not
+     compile, let alone run correctly.  This is currently used only for
+     the unsupported i960 Nindy target, and should not be used in any
+     other configuration.
+
+`BELIEVE_PCC_PROMOTION'
+     Define if the compiler promotes a short or char parameter to an
+     int, but still reports the parameter as its original type, rather
+     than the promoted type.
+
+`BELIEVE_PCC_PROMOTION_TYPE'
+     Define this if GDB should believe the type of a short argument when
+     compiled by pcc, but look within a full int space to get its value.
+     Only defined for Sun-3 at present.
+
+`BITS_BIG_ENDIAN'
+     Define this if the numbering of bits in the targets does *not*
+     match the endianness of the target byte order.  A value of 1 means
+     that the bits are numbered in a big-endian order, 0 means
+     little-endian.
+
+`BREAKPOINT'
+     This is the character array initializer for the bit pattern to put
+     into memory where a breakpoint is set.  Although it's common to
+     use a trap instruction for a breakpoint, it's not required; for
+     instance, the bit pattern could be an invalid instruction.  The
+     breakpoint must be no longer than the shortest instruction of the
+     architecture.
+
+`BIG_BREAKPOINT'
+
+`LITTLE_BREAKPOINT'
+     Similar to BREAKPOINT, but used for bi-endian targets.
+
+`REMOTE_BREAKPOINT'
+
+`LITTLE_REMOTE_BREAKPOINT'
+
+`BIG_REMOTE_BREAKPOINT'
+     Similar to BREAKPOINT, but used for remote targets.
+
+`BREAKPOINT_FROM_PC (pcptr, lenptr)'
+     Use the program counter to determine the contents and size of a
+     breakpoint instruction.  It returns a pointer to a string of bytes
+     that encode a breakpoint instruction, stores the length of the
+     string to *lenptr, and adjusts pc (if necessary) to point to the
+     actual memory location where the breakpoint should be inserted.
+
+     Although it is common to use a trap instruction for a breakpoint,
+     it's not required; for instance, the bit pattern could be an
+     invalid instruction.  The breakpoint must be no longer than the
+     shortest instruction of the architecture.
+
+     Replaces all the other BREAKPOINTs.
+
+`CALL_DUMMY'
+     valops.c
+
+`CALL_DUMMY_LOCATION'
+     inferior.h
+
+`CALL_DUMMY_STACK_ADJUST'
+     valops.c
+
+`CANNOT_FETCH_REGISTER (regno)'
+     A C expression that should be nonzero if REGNO cannot be fetched
+     from an inferior process.  This is only relevant if
+     `FETCH_INFERIOR_REGISTERS' is not defined.
+
+`CANNOT_STORE_REGISTER (regno)'
+     A C expression that should be nonzero if REGNO should not be
+     written to the target.  This is often the case for program
+     counters, status words, and other special registers.  If this is
+     not defined, GDB will assume that all registers may be written.
+
+`DO_DEFERRED_STORES'
+
+`CLEAR_DEFERRED_STORES'
+     Define this to execute any deferred stores of registers into the
+     inferior, and to cancel any deferred stores.
+
+     Currently only implemented correctly for native Sparc
+     configurations?
+
+`CPLUS_MARKER'
+     Define this to expand into the character that G++ uses to
+     distinguish compiler-generated identifiers from
+     programmer-specified identifiers.  By default, this expands into
+     `'$''.  Most System V targets should define this to `'.''.
+
+`DBX_PARM_SYMBOL_CLASS'
+     Hook for the `SYMBOL_CLASS' of a parameter when decoding DBX symbol
+     information.  In the i960, parameters can be stored as locals or as
+     args, depending on the type of the debug record.
+
+`DECR_PC_AFTER_BREAK'
+     Define this to be the amount by which to decrement the PC after the
+     program encounters a breakpoint.  This is often the number of
+     bytes in BREAKPOINT, though not always.  For most targets this
+     value will be 0.
+
+`DECR_PC_AFTER_HW_BREAK'
+     Similarly, for hardware breakpoints.
+
+`DISABLE_UNSETTABLE_BREAK addr'
+     If defined, this should evaluate to 1 if ADDR is in a shared
+     library in which breakpoints cannot be set and so should be
+     disabled.
+
+`DO_REGISTERS_INFO'
+     If defined, use this to print the value of a register or all
+     registers.
+
+`END_OF_TEXT_DEFAULT'
+     This is an expression that should designate the end of the text
+     section (? FIXME ?)
+
+`EXTRACT_RETURN_VALUE(type,regbuf,valbuf)'
+     Define this to extract a function's return value of type TYPE from
+     the raw register state REGBUF and copy that, in virtual format,
+     into VALBUF.
+
+`EXTRACT_STRUCT_VALUE_ADDRESS(regbuf)'
+     Define this to extract from an array REGBUF containing the (raw)
+     register state, the address in which a function should return its
+     structure value, as a CORE_ADDR (or an expression that can be used
+     as one).
+
+`FLOAT_INFO'
+     If defined, then the `info float' command will print information
+     about the processor's floating point unit.
+
+`FP_REGNUM'
+     The number of the frame pointer register.
+
+`FRAMELESS_FUNCTION_INVOCATION(fi, frameless)'
+     Define this to set the variable FRAMELESS to 1 if the function
+     invocation represented by FI does not have a stack frame
+     associated with it.  Otherwise set it to 0.
+
+`FRAME_ARGS_ADDRESS_CORRECT'
+     stack.c
+
+`FRAME_CHAIN(frame)'
+     Given FRAME, return a pointer to the calling frame.
+
+`FRAME_CHAIN_COMBINE(chain,frame)'
+     Define this to take the frame chain pointer and the frame's nominal
+     address and produce the nominal address of the caller's frame.
+     Presently only defined for HP PA.
+
+`FRAME_CHAIN_VALID(chain,thisframe)'
+     Define this to be an expression that returns zero if the given
+     frame is an outermost frame, with no caller, and nonzero
+     otherwise.  Three common definitions are available.
+     `default_frame_chain_valid' (the default) is nonzero if the chain
+     pointer is nonzero and given frame's PC is not inside the startup
+     file (such as `crt0.o').  `alternate_frame_chain_valid' is nonzero
+     if the chain pointer is nonzero and the given frame's PC is not in
+     `main()' or a known entry point function (such as `_start()').
+
+`FRAME_INIT_SAVED_REGS(frame)'
+     See `frame.h'.  Determines the address of all registers in the
+     current stack frame storing each in `frame->saved_regs'.  Space for
+     `frame->saved_regs' shall be allocated by `FRAME_INIT_SAVED_REGS'
+     using either `frame_saved_regs_zalloc' or `frame_obstack_alloc'.
+
+     FRAME_FIND_SAVED_REGS and EXTRA_FRAME_INFO are deprecated.
+
+`FRAME_NUM_ARGS (val, fi)'
+     For the frame described by FI, set VAL to the number of arguments
+     that are being passed.
+
+`FRAME_SAVED_PC(frame)'
+     Given FRAME, return the pc saved there.  That is, the return
+     address.
+
+`FUNCTION_EPILOGUE_SIZE'
+     For some COFF targets, the `x_sym.x_misc.x_fsize' field of the
+     function end symbol is 0.  For such targets, you must define
+     `FUNCTION_EPILOGUE_SIZE' to expand into the standard size of a
+     function's epilogue.
+
+`GCC_COMPILED_FLAG_SYMBOL'
+
+`GCC2_COMPILED_FLAG_SYMBOL'
+     If defined, these are the names of the symbols that GDB will look
+     for to detect that GCC compiled the file.  The default symbols are
+     `gcc_compiled.' and `gcc2_compiled.', respectively. (Currently
+     only defined for the Delta 68.)
+
+`GDB_TARGET_IS_HPPA'
+     This determines whether horrible kludge code in dbxread.c and
+     partial-stab.h is used to mangle multiple-symbol-table files from
+     HPPA's.  This should all be ripped out, and a scheme like elfread.c
+     used.
+
+`GDB_TARGET_IS_MACH386'
+
+`GDB_TARGET_IS_SUN3'
+
+`GDB_TARGET_IS_SUN386'
+     Kludges that should go away.
+
+`GET_LONGJMP_TARGET'
+     For most machines, this is a target-dependent parameter.  On the
+     DECstation and the Iris, this is a native-dependent parameter,
+     since <setjmp.h> is needed to define it.
+
+     This macro determines the target PC address that longjmp() will
+     jump to, assuming that we have just stopped at a longjmp
+     breakpoint.  It takes a CORE_ADDR * as argument, and stores the
+     target PC value through this pointer.  It examines the current
+     state of the machine as needed.
+
+`GET_SAVED_REGISTER'
+     Define this if you need to supply your own definition for the
+     function `get_saved_register'.  Currently this is only done for
+     the a29k.
+
+`HAVE_REGISTER_WINDOWS'
+     Define this if the target has register windows.
+
+`REGISTER_IN_WINDOW_P (regnum)'
+     Define this to be an expression that is 1 if the given register is
+     in the window.
+
+`IBM6000_TARGET'
+     Shows that we are configured for an IBM RS/6000 target.  This
+     conditional should be eliminated (FIXME) and replaced by
+     feature-specific macros.  It was introduced in haste and we are
+     repenting at leisure.
+
+`IEEE_FLOAT'
+     Define this if the target system uses IEEE-format floating point
+     numbers.
+
+`INIT_EXTRA_FRAME_INFO (fromleaf, frame)'
+     If additional information about the frame is required this should
+     be stored in `frame->extra_info'.  Space for `frame->extra_info'
+     is allocated using `frame_obstack_alloc'.
+
+`INIT_FRAME_PC (fromleaf, prev)'
+     This is a C statement that sets the pc of the frame pointed to by
+     PREV.  [By default...]
+
+`INNER_THAN (lhs,rhs)'
+     Returns non-zero if stack address LHS is inner than (nearer to the
+     stack top) stack address RHS. Define this as `lhs < rhs' if the
+     target's stack grows downward in memory, or `lhs > rsh' if the
+     stack grows upward.
+
+`IN_SIGTRAMP (pc, name)'
+     Define this to return true if the given PC and/or NAME indicates
+     that the current function is a sigtramp.
+
+`SIGTRAMP_START (pc)'
+
+`SIGTRAMP_END (pc)'
+     Define these to be the start and end address of the sigtramp for
+     the given PC.  On machines where the address is just a compile time
+     constant, the macro expansion will typically just ignore the
+     supplied PC.
+
+`IN_SOLIB_CALL_TRAMPOLINE pc name'
+     Define this to evaluate to nonzero if the program is stopped in the
+     trampoline that connects to a shared library.
+
+`IN_SOLIB_RETURN_TRAMPOLINE pc name'
+     Define this to evaluate to nonzero if the program is stopped in the
+     trampoline that returns from a shared library.
+
+`IS_TRAPPED_INTERNALVAR (name)'
+     This is an ugly hook to allow the specification of special actions
+     that should occur as a side-effect of setting the value of a
+     variable internal to GDB.  Currently only used by the h8500.  Note
+     that this could be either a host or target conditional.
+
+`NEED_TEXT_START_END'
+     Define this if GDB should determine the start and end addresses of
+     the text section.  (Seems dubious.)
+
+`NO_HIF_SUPPORT'
+     (Specific to the a29k.)
+
+`SOFTWARE_SINGLE_STEP_P'
+     Define this as 1 if the target does not have a hardware single-step
+     mechanism. The macro `SOFTWARE_SINGLE_STEP' must also be defined.
+
+`SOFTWARE_SINGLE_STEP(signal,insert_breapoints_p)'
+     A function that inserts or removes (dependant on
+     INSERT_BREAPOINTS_P) breakpoints at each possible destinations of
+     the next instruction. See `sparc-tdep.c' and `rs6000-tdep.c' for
+     examples.
+
+`PCC_SOL_BROKEN'
+     (Used only in the Convex target.)
+
+`PC_IN_CALL_DUMMY'
+     inferior.h
+
+`PC_LOAD_SEGMENT'
+     If defined, print information about the load segment for the
+     program counter.  (Defined only for the RS/6000.)
+
+`PC_REGNUM'
+     If the program counter is kept in a register, then define this
+     macro to be the number of that register.  This need be defined
+     only if `TARGET_WRITE_PC' is not defined.
+
+`NPC_REGNUM'
+     The number of the "next program counter" register, if defined.
+
+`NNPC_REGNUM'
+     The number of the "next next program counter" register, if defined.
+     Currently, this is only defined for the Motorola 88K.
+
+`PRINT_REGISTER_HOOK (regno)'
+     If defined, this must be a function that prints the contents of the
+     given register to standard output.
+
+`PRINT_TYPELESS_INTEGER'
+     This is an obscure substitute for `print_longest' that seems to
+     have been defined for the Convex target.
+
+`PROCESS_LINENUMBER_HOOK'
+     A hook defined for XCOFF reading.
+
+`PROLOGUE_FIRSTLINE_OVERLAP'
+     (Only used in unsupported Convex configuration.)
+
+`PS_REGNUM'
+     If defined, this is the number of the processor status register.
+     (This definition is only used in generic code when parsing "$ps".)
+
+`POP_FRAME'
+     Used in `call_function_by_hand' to remove an artificial stack
+     frame.
+
+`PUSH_ARGUMENTS (nargs, args, sp, struct_return, struct_addr)'
+     Define this to push arguments onto the stack for inferior function
+     call.
+
+`PUSH_DUMMY_FRAME'
+     Used in `call_function_by_hand' to create an artificial stack
+     frame.
+
+`REGISTER_BYTES'
+     The total amount of space needed to store GDB's copy of the
+     machine's register state.
+
+`REGISTER_NAME(i)'
+     Return the name of register I as a string.  May return NULL or NUL
+     to indicate that register I is not valid.
+
+`REG_STRUCT_HAS_ADDR (gcc_p, type)'
+     Define this to return 1 if the given type will be passed by pointer
+     rather than directly.
+
+`SDB_REG_TO_REGNUM'
+     Define this to convert sdb register numbers into GDB regnums.  If
+     not defined, no conversion will be done.
+
+`SHIFT_INST_REGS'
+     (Only used for m88k targets.)
+
+`SKIP_PROLOGUE (pc)'
+     A C statement that advances the PC across any function entry
+     prologue instructions so as to reach "real" code.
+
+`SKIP_PROLOGUE_FRAMELESS_P'
+     A C statement that should behave similarly, but that can stop as
+     soon as the function is known to have a frame.  If not defined,
+     `SKIP_PROLOGUE' will be used instead.
+
+`SKIP_TRAMPOLINE_CODE (pc)'
+     If the target machine has trampoline code that sits between
+     callers and the functions being called, then define this macro to
+     return a new PC that is at the start of the real function.
+
+`SP_REGNUM'
+     Define this to be the number of the register that serves as the
+     stack pointer.
+
+`STAB_REG_TO_REGNUM'
+     Define this to convert stab register numbers (as gotten from `r'
+     declarations) into GDB regnums.  If not defined, no conversion
+     will be done.
+
+`STACK_ALIGN (addr)'
+     Define this to adjust the address to the alignment required for the
+     processor's stack.
+
+`STEP_SKIPS_DELAY (addr)'
+     Define this to return true if the address is of an instruction
+     with a delay slot.  If a breakpoint has been placed in the
+     instruction's delay slot, GDB will single-step over that
+     instruction before resuming normally.  Currently only defined for
+     the Mips.
+
+`STORE_RETURN_VALUE (type, valbuf)'
+     A C expression that stores a function return value of type TYPE,
+     where VALBUF is the address of the value to be stored.
+
+`SUN_FIXED_LBRAC_BUG'
+     (Used only for Sun-3 and Sun-4 targets.)
+
+`SYMBOL_RELOADING_DEFAULT'
+     The default value of the `symbol-reloading' variable.  (Never
+     defined in current sources.)
+
+`TARGET_BYTE_ORDER_DEFAULT'
+     The ordering of bytes in the target.  This must be either
+     `BIG_ENDIAN' or `LITTLE_ENDIAN'.  This macro replaces
+     TARGET_BYTE_ORDER which is deprecated.
+
+`TARGET_BYTE_ORDER_SELECTABLE_P'
+     Non-zero if the target has both `BIG_ENDIAN' and `LITTLE_ENDIAN'
+     variants.  This macro replaces TARGET_BYTE_ORDER_SELECTABLE which
+     is deprecated.
+
+`TARGET_CHAR_BIT'
+     Number of bits in a char; defaults to 8.
+
+`TARGET_COMPLEX_BIT'
+     Number of bits in a complex number; defaults to `2 *
+     TARGET_FLOAT_BIT'.
+
+`TARGET_DOUBLE_BIT'
+     Number of bits in a double float; defaults to `8 *
+     TARGET_CHAR_BIT'.
+
+`TARGET_DOUBLE_COMPLEX_BIT'
+     Number of bits in a double complex; defaults to `2 *
+     TARGET_DOUBLE_BIT'.
+
+`TARGET_FLOAT_BIT'
+     Number of bits in a float; defaults to `4 * TARGET_CHAR_BIT'.
+
+`TARGET_INT_BIT'
+     Number of bits in an integer; defaults to `4 * TARGET_CHAR_BIT'.
+
+`TARGET_LONG_BIT'
+     Number of bits in a long integer; defaults to `4 *
+     TARGET_CHAR_BIT'.
+
+`TARGET_LONG_DOUBLE_BIT'
+     Number of bits in a long double float; defaults to `2 *
+     TARGET_DOUBLE_BIT'.
+
+`TARGET_LONG_LONG_BIT'
+     Number of bits in a long long integer; defaults to `2 *
+     TARGET_LONG_BIT'.
+
+`TARGET_PTR_BIT'
+     Number of bits in a pointer; defaults to `TARGET_INT_BIT'.
+
+`TARGET_SHORT_BIT'
+     Number of bits in a short integer; defaults to `2 *
+     TARGET_CHAR_BIT'.
+
+`TARGET_READ_PC'
+
+`TARGET_WRITE_PC (val, pid)'
+
+`TARGET_READ_SP'
+
+`TARGET_WRITE_SP'
+
+`TARGET_READ_FP'
+
+`TARGET_WRITE_FP'
+     These change the behavior of `read_pc', `write_pc', `read_sp',
+     `write_sp', `read_fp' and `write_fp'.  For most targets, these may
+     be left undefined.  GDB will call the read and write register
+     functions with the relevant `_REGNUM' argument.
+
+     These macros are useful when a target keeps one of these registers
+     in a hard to get at place; for example, part in a segment register
+     and part in an ordinary register.
+
+`TARGET_VIRTUAL_FRAME_POINTER(pc,regp,offsetp)'
+     Returns a `(register, offset)' pair representing the virtual frame
+     pointer in use at the code address `"pc"'.  If virtual frame
+     pointers are not used, a default definition simply returns
+     `FP_REGNUM', with an offset of zero.
+
+`USE_STRUCT_CONVENTION (gcc_p, type)'
+     If defined, this must be an expression that is nonzero if a value
+     of the given TYPE being returned from a function must have space
+     allocated for it on the stack.  GCC_P is true if the function
+     being considered is known to have been compiled by GCC; this is
+     helpful for systems where GCC is known to use different calling
+     convention than other compilers.
+
+`VARIABLES_INSIDE_BLOCK (desc, gcc_p)'
+     For dbx-style debugging information, if the compiler puts variable
+     declarations inside LBRAC/RBRAC blocks, this should be defined to
+     be nonzero.  DESC is the value of `n_desc' from the `N_RBRAC'
+     symbol, and GCC_P is true if GDB has noticed the presence of
+     either the `GCC_COMPILED_SYMBOL' or the `GCC2_COMPILED_SYMBOL'.
+     By default, this is 0.
+
+`OS9K_VARIABLES_INSIDE_BLOCK (desc, gcc_p)'
+     Similarly, for OS/9000.  Defaults to 1.
+
+   Motorola M68K target conditionals.
+
+`BPT_VECTOR'
+     Define this to be the 4-bit location of the breakpoint trap
+     vector.  If not defined, it will default to `0xf'.
+
+`REMOTE_BPT_VECTOR'
+     Defaults to `1'.
+
+Adding a New Target
+===================
+
+   The following files define a target to GDB:
+
+`gdb/config/ARCH/TTT.mt'
+     Contains a Makefile fragment specific to this target.  Specifies
+     what object files are needed for target TTT, by defining
+     `TDEPFILES=...'.  Also specifies the header file which describes
+     TTT, by defining `TM_FILE= tm-TTT.h'.  You can also define
+     `TM_CFLAGS', `TM_CLIBS', `TM_CDEPS', but these are now deprecated
+     and may go away in future versions of GDB.
+
+`gdb/config/ARCH/tm-TTT.h'
+     (`tm.h' is a link to this file, created by configure).  Contains
+     macro definitions about the target machine's registers, stack frame
+     format and instructions.
+
+`gdb/TTT-tdep.c'
+     Contains any miscellaneous code required for this target machine.
+     On some machines it doesn't exist at all.  Sometimes the macros in
+     `tm-TTT.h' become very complicated, so they are implemented as
+     functions here instead, and the macro is simply defined to call the
+     function.  This is vastly preferable, since it is easier to
+     understand and debug.
+
+`gdb/config/ARCH/tm-ARCH.h'
+     This often exists to describe the basic layout of the target
+     machine's processor chip (registers, stack, etc).  If used, it is
+     included by `tm-TTT.h'.  It can be shared among many targets that
+     use the same processor.
+
+`gdb/ARCH-tdep.c'
+     Similarly, there are often common subroutines that are shared by
+     all target machines that use this particular architecture.
+
+   If you are adding a new operating system for an existing CPU chip,
+add a `config/tm-OS.h' file that describes the operating system
+facilities that are unusual (extra symbol table info; the breakpoint
+instruction needed; etc).  Then write a `ARCH/tm-OS.h' that just
+`#include's `tm-ARCH.h' and `config/tm-OS.h'.
+
+
+File: gdbint.info,  Node: Target Vector Definition,  Next: Native Debugging,  Prev: Target Architecture Definition,  Up: Top
+
+Target Vector Definition
+************************
+
+   The target vector defines the interface between GDB's abstract
+handling of target systems, and the nitty-gritty code that actually
+exercises control over a process or a serial port.  GDB includes some
+30-40 different target vectors; however, each configuration of GDB
+includes only a few of them.
+
+File Targets
+============
+
+   Both executables and core files have target vectors.
+
+Standard Protocol and Remote Stubs
+==================================
+
+   GDB's file `remote.c' talks a serial protocol to code that runs in
+the target system.  GDB provides several sample "stubs" that can be
+integrated into target programs or operating systems for this purpose;
+they are named `*-stub.c'.
+
+   The GDB user's manual describes how to put such a stub into your
+target code.  What follows is a discussion of integrating the SPARC
+stub into a complicated operating system (rather than a simple
+program), by Stu Grossman, the author of this stub.
+
+   The trap handling code in the stub assumes the following upon entry
+to trap_low:
+
+  1. %l1 and %l2 contain pc and npc respectively at the time of the trap
+
+  2. traps are disabled
+
+  3. you are in the correct trap window
+
+
+   As long as your trap handler can guarantee those conditions, then
+there is no reason why you shouldn't be able to `share' traps with the
+stub.  The stub has no requirement that it be jumped to directly from
+the hardware trap vector.  That is why it calls `exceptionHandler()',
+which is provided by the external environment.  For instance, this could
+setup the hardware traps to actually execute code which calls the stub
+first, and then transfers to its own trap handler.
+
+   For the most point, there probably won't be much of an issue with
+`sharing' traps, as the traps we use are usually not used by the kernel,
+and often indicate unrecoverable error conditions.  Anyway, this is all
+controlled by a table, and is trivial to modify.  The most important
+trap for us is for `ta 1'.  Without that, we can't single step or do
+breakpoints.  Everything else is unnecessary for the proper operation
+of the debugger/stub.
+
+   From reading the stub, it's probably not obvious how breakpoints
+work.  They are simply done by deposit/examine operations from GDB.
+
+ROM Monitor Interface
+=====================
+
+Custom Protocols
+================
+
+Transport Layer
+===============
+
+Builtin Simulator
+=================
+
+
+File: gdbint.info,  Node: Native Debugging,  Next: Support Libraries,  Prev: Target Vector Definition,  Up: Top
+
+Native Debugging
+****************
+
+   Several files control GDB's configuration for native support:
+
+`gdb/config/ARCH/XYZ.mh'
+     Specifies Makefile fragments needed when hosting *or native* on
+     machine XYZ.  In particular, this lists the required
+     native-dependent object files, by defining `NATDEPFILES=...'.
+     Also specifies the header file which describes native support on
+     XYZ, by defining `NAT_FILE= nm-XYZ.h'.  You can also define
+     `NAT_CFLAGS', `NAT_ADD_FILES', `NAT_CLIBS', `NAT_CDEPS', etc.; see
+     `Makefile.in'.
+
+`gdb/config/ARCH/nm-XYZ.h'
+     (`nm.h' is a link to this file, created by configure).  Contains C
+     macro definitions describing the native system environment, such as
+     child process control and core file support.
+
+`gdb/XYZ-nat.c'
+     Contains any miscellaneous C code required for this native support
+     of this machine.  On some machines it doesn't exist at all.
+
+   There are some "generic" versions of routines that can be used by
+various systems.  These can be customized in various ways by macros
+defined in your `nm-XYZ.h' file.  If these routines work for the XYZ
+host, you can just include the generic file's name (with `.o', not
+`.c') in `NATDEPFILES'.
+
+   Otherwise, if your machine needs custom support routines, you will
+need to write routines that perform the same functions as the generic
+file.  Put them into `XYZ-nat.c', and put `XYZ-nat.o' into
+`NATDEPFILES'.
+
+`inftarg.c'
+     This contains the *target_ops vector* that supports Unix child
+     processes on systems which use ptrace and wait to control the
+     child.
+
+`procfs.c'
+     This contains the *target_ops vector* that supports Unix child
+     processes on systems which use /proc to control the child.
+
+`fork-child.c'
+     This does the low-level grunge that uses Unix system calls to do a
+     "fork and exec" to start up a child process.
+
+`infptrace.c'
+     This is the low level interface to inferior processes for systems
+     using the Unix `ptrace' call in a vanilla way.
+
+Native core file Support
+========================
+
+`core-aout.c::fetch_core_registers()'
+     Support for reading registers out of a core file.  This routine
+     calls `register_addr()', see below.  Now that BFD is used to read
+     core files, virtually all machines should use `core-aout.c', and
+     should just provide `fetch_core_registers' in `XYZ-nat.c' (or
+     `REGISTER_U_ADDR' in `nm-XYZ.h').
+
+`core-aout.c::register_addr()'
+     If your `nm-XYZ.h' file defines the macro `REGISTER_U_ADDR(addr,
+     blockend, regno)', it should be defined to set `addr' to the
+     offset within the `user' struct of GDB register number `regno'.
+     `blockend' is the offset within the "upage" of `u.u_ar0'.  If
+     `REGISTER_U_ADDR' is defined, `core-aout.c' will define the
+     `register_addr()' function and use the macro in it.  If you do not
+     define `REGISTER_U_ADDR', but you are using the standard
+     `fetch_core_registers()', you will need to define your own version
+     of `register_addr()', put it into your `XYZ-nat.c' file, and be
+     sure `XYZ-nat.o' is in the `NATDEPFILES' list.  If you have your
+     own `fetch_core_registers()', you may not need a separate
+     `register_addr()'.  Many custom `fetch_core_registers()'
+     implementations simply locate the registers themselves.
+
+   When making GDB run native on a new operating system, to make it
+possible to debug core files, you will need to either write specific
+code for parsing your OS's core files, or customize `bfd/trad-core.c'.
+First, use whatever `#include' files your machine uses to define the
+struct of registers that is accessible (possibly in the u-area) in a
+core file (rather than `machine/reg.h'), and an include file that
+defines whatever header exists on a core file (e.g. the u-area or a
+`struct core').  Then modify `trad_unix_core_file_p()' to use these
+values to set up the section information for the data segment, stack
+segment, any other segments in the core file (perhaps shared library
+contents or control information), "registers" segment, and if there are
+two discontiguous sets of registers (e.g.  integer and float), the
+"reg2" segment.  This section information basically delimits areas in
+the core file in a standard way, which the section-reading routines in
+BFD know how to seek around in.
+
+   Then back in GDB, you need a matching routine called
+`fetch_core_registers()'.  If you can use the generic one, it's in
+`core-aout.c'; if not, it's in your `XYZ-nat.c' file.  It will be
+passed a char pointer to the entire "registers" segment, its length,
+and a zero; or a char pointer to the entire "regs2" segment, its
+length, and a 2.  The routine should suck out the supplied register
+values and install them into GDB's "registers" array.
+
+   If your system uses `/proc' to control processes, and uses ELF
+format core files, then you may be able to use the same routines for
+reading the registers out of processes and out of core files.
+
+ptrace
+======
+
+/proc
+=====
+
+win32
+=====
+
+shared libraries
+================
+
+Native Conditionals
+===================
+
+   When GDB is configured and compiled, various macros are defined or
+left undefined, to control compilation when the host and target systems
+are the same.  These macros should be defined (or left undefined) in
+`nm-SYSTEM.h'.
+
+`ATTACH_DETACH'
+     If defined, then GDB will include support for the `attach' and
+     `detach' commands.
+
+`CHILD_PREPARE_TO_STORE'
+     If the machine stores all registers at once in the child process,
+     then define this to ensure that all values are correct.  This
+     usually entails a read from the child.
+
+     [Note that this is incorrectly defined in `xm-SYSTEM.h' files
+     currently.]
+
+`FETCH_INFERIOR_REGISTERS'
+     Define this if the native-dependent code will provide its own
+     routines `fetch_inferior_registers' and `store_inferior_registers'
+     in `HOST-nat.c'.  If this symbol is *not* defined, and
+     `infptrace.c' is included in this configuration, the default
+     routines in `infptrace.c' are used for these functions.
+
+`FILES_INFO_HOOK'
+     (Only defined for Convex.)
+
+`FP0_REGNUM'
+     This macro is normally defined to be the number of the first
+     floating point register, if the machine has such registers.  As
+     such, it would appear only in target-specific code.  However,
+     /proc support uses this to decide whether floats are in use on
+     this target.
+
+`GET_LONGJMP_TARGET'
+     For most machines, this is a target-dependent parameter.  On the
+     DECstation and the Iris, this is a native-dependent parameter,
+     since <setjmp.h> is needed to define it.
+
+     This macro determines the target PC address that longjmp() will
+     jump to, assuming that we have just stopped at a longjmp
+     breakpoint.  It takes a CORE_ADDR * as argument, and stores the
+     target PC value through this pointer.  It examines the current
+     state of the machine as needed.
+
+`KERNEL_U_ADDR'
+     Define this to the address of the `u' structure (the "user
+     struct", also known as the "u-page") in kernel virtual memory.  GDB
+     needs to know this so that it can subtract this address from
+     absolute addresses in the upage, that are obtained via ptrace or
+     from core files.  On systems that don't need this value, set it to
+     zero.
+
+`KERNEL_U_ADDR_BSD'
+     Define this to cause GDB to determine the address of `u' at
+     runtime, by using Berkeley-style `nlist' on the kernel's image in
+     the root directory.
+
+`KERNEL_U_ADDR_HPUX'
+     Define this to cause GDB to determine the address of `u' at
+     runtime, by using HP-style `nlist' on the kernel's image in the
+     root directory.
+
+`ONE_PROCESS_WRITETEXT'
+     Define this to be able to, when a breakpoint insertion fails, warn
+     the user that another process may be running with the same
+     executable.
+
+`PROC_NAME_FMT'
+     Defines the format for the name of a `/proc' device.  Should be
+     defined in `nm.h' *only* in order to override the default
+     definition in `procfs.c'.
+
+`PTRACE_FP_BUG'
+     mach386-xdep.c
+
+`PTRACE_ARG3_TYPE'
+     The type of the third argument to the `ptrace' system call, if it
+     exists and is different from `int'.
+
+`REGISTER_U_ADDR'
+     Defines the offset of the registers in the "u area".
+
+`SHELL_COMMAND_CONCAT'
+     If defined, is a string to prefix on the shell command used to
+     start the inferior.
+
+`SHELL_FILE'
+     If defined, this is the name of the shell to use to run the
+     inferior.  Defaults to `"/bin/sh"'.
+
+`SOLIB_ADD (filename, from_tty, targ)'
+     Define this to expand into an expression that will cause the
+     symbols in FILENAME to be added to GDB's symbol table.
+
+`SOLIB_CREATE_INFERIOR_HOOK'
+     Define this to expand into any shared-library-relocation code that
+     you want to be run just after the child process has been forked.
+
+`START_INFERIOR_TRAPS_EXPECTED'
+     When starting an inferior, GDB normally expects to trap twice;
+     once when the shell execs, and once when the program itself execs.
+     If the actual number of traps is something other than 2, then
+     define this macro to expand into the number expected.
+
+`SVR4_SHARED_LIBS'
+     Define this to indicate that SVR4-style shared libraries are in
+     use.
+
+`USE_PROC_FS'
+     This determines whether small routines in `*-tdep.c', which
+     translate register values between GDB's internal representation
+     and the /proc representation, are compiled.
+
+`U_REGS_OFFSET'
+     This is the offset of the registers in the upage.  It need only be
+     defined if the generic ptrace register access routines in
+     `infptrace.c' are being used (that is, `infptrace.c' is configured
+     in, and `FETCH_INFERIOR_REGISTERS' is not defined).  If the
+     default value from `infptrace.c' is good enough, leave it
+     undefined.
+
+     The default value means that u.u_ar0 *points to* the location of
+     the registers.  I'm guessing that `#define U_REGS_OFFSET 0' means
+     that u.u_ar0 *is* the location of the registers.
+
+`CLEAR_SOLIB'
+     objfiles.c
+
+`DEBUG_PTRACE'
+     Define this to debug ptrace calls.
+
+
+File: gdbint.info,  Node: Support Libraries,  Next: Coding,  Prev: Native Debugging,  Up: Top
+
+Support Libraries
+*****************
+
+BFD
+===
+
+   BFD provides support for GDB in several ways:
+
+*identifying executable and core files*
+     BFD will identify a variety of file types, including a.out, coff,
+     and several variants thereof, as well as several kinds of core
+     files.
+
+*access to sections of files*
+     BFD parses the file headers to determine the names, virtual
+     addresses, sizes, and file locations of all the various named
+     sections in files (such as the text section or the data section).
+     GDB simply calls BFD to read or write section X at byte offset Y
+     for length Z.
+
+*specialized core file support*
+     BFD provides routines to determine the failing command name stored
+     in a core file, the signal with which the program failed, and
+     whether a core file matches (i.e. could be a core dump of) a
+     particular executable file.
+
+*locating the symbol information*
+     GDB uses an internal interface of BFD to determine where to find
+     the symbol information in an executable file or symbol-file.  GDB
+     itself handles the reading of symbols, since BFD does not
+     "understand" debug symbols, but GDB uses BFD's cached information
+     to find the symbols, string table, etc.
+
+opcodes
+=======
+
+   The opcodes library provides GDB's disassembler.  (It's a separate
+library because it's also used in binutils, for `objdump').
+
+readline
+========
+
+mmalloc
+=======
+
+libiberty
+=========
+
+gnu-regex
+=========
+
+   Regex conditionals.
+
+`C_ALLOCA'
+
+`NFAILURES'
+
+`RE_NREGS'
+
+`SIGN_EXTEND_CHAR'
+
+`SWITCH_ENUM_BUG'
+
+`SYNTAX_TABLE'
+
+`Sword'
+
+`sparc'
+include
+=======
+
+
+File: gdbint.info,  Node: Coding,  Next: Porting GDB,  Prev: Support Libraries,  Up: Top
+
+Coding
+******
+
+   This chapter covers topics that are lower-level than the major
+algorithms of GDB.
+
+Cleanups
+========
+
+   Cleanups are a structured way to deal with things that need to be
+done later.  When your code does something (like `malloc' some memory,
+or open a file) that needs to be undone later (e.g. free the memory or
+close the file), it can make a cleanup.  The cleanup will be done at
+some future point: when the command is finished, when an error occurs,
+or when your code decides it's time to do cleanups.
+
+   You can also discard cleanups, that is, throw them away without doing
+what they say.  This is only done if you ask that it be done.
+
+   Syntax:
+
+`struct cleanup *OLD_CHAIN;'
+     Declare a variable which will hold a cleanup chain handle.
+
+`OLD_CHAIN = make_cleanup (FUNCTION, ARG);'
+     Make a cleanup which will cause FUNCTION to be called with ARG (a
+     `char *') later.  The result, OLD_CHAIN, is a handle that can be
+     passed to `do_cleanups' or `discard_cleanups' later.  Unless you
+     are going to call `do_cleanups' or `discard_cleanups' yourself,
+     you can ignore the result from `make_cleanup'.
+
+`do_cleanups (OLD_CHAIN);'
+     Perform all cleanups done since `make_cleanup' returned OLD_CHAIN.
+     E.g.:
+          make_cleanup (a, 0);
+          old = make_cleanup (b, 0);
+          do_cleanups (old);
+
+     will call `b()' but will not call `a()'.  The cleanup that calls
+     `a()' will remain in the cleanup chain, and will be done later
+     unless otherwise discarded.
+
+`discard_cleanups (OLD_CHAIN);'
+     Same as `do_cleanups' except that it just removes the cleanups from
+     the chain and does not call the specified functions.
+
+   Some functions, e.g. `fputs_filtered()' or `error()', specify that
+they "should not be called when cleanups are not in place".  This means
+that any actions you need to reverse in the case of an error or
+interruption must be on the cleanup chain before you call these
+functions, since they might never return to your code (they `longjmp'
+instead).
+
+Wrapping Output Lines
+=====================
+
+   Output that goes through `printf_filtered' or `fputs_filtered' or
+`fputs_demangled' needs only to have calls to `wrap_here' added in
+places that would be good breaking points.  The utility routines will
+take care of actually wrapping if the line width is exceeded.
+
+   The argument to `wrap_here' is an indentation string which is
+printed *only* if the line breaks there.  This argument is saved away
+and used later.  It must remain valid until the next call to
+`wrap_here' or until a newline has been printed through the
+`*_filtered' functions.  Don't pass in a local variable and then return!
+
+   It is usually best to call `wrap_here()' after printing a comma or
+space.  If you call it before printing a space, make sure that your
+indentation properly accounts for the leading space that will print if
+the line wraps there.
+
+   Any function or set of functions that produce filtered output must
+finish by printing a newline, to flush the wrap buffer, before switching
+to unfiltered ("`printf'") output.  Symbol reading routines that print
+warnings are a good example.
+
+GDB Coding Standards
+====================
+
+   GDB follows the GNU coding standards, as described in
+`etc/standards.texi'.  This file is also available for anonymous FTP
+from GNU archive sites.  GDB takes a strict interpretation of the
+standard; in general, when the GNU standard recommends a practice but
+does not require it, GDB requires it.
+
+   GDB follows an additional set of coding standards specific to GDB,
+as described in the following sections.
+
+   You can configure with `--enable-build-warnings' to get GCC to check
+on a number of these rules.  GDB sources ought not to engender any
+complaints, unless they are caused by bogus host systems.  (The exact
+set of enabled warnings is currently `-Wall -Wpointer-arith
+-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations'.
+
+Formatting
+----------
+
+   The standard GNU recommendations for formatting must be followed
+strictly.
+
+   Note that while in a definition, the function's name must be in
+column zero; in a function declaration, the name must be on the same
+line as the return type.
+
+   In addition, there must be a space between a function or macro name
+and the opening parenthesis of its argument list (except for macro
+definitions, as required by C).  There must not be a space after an open
+paren/bracket or before a close paren/bracket.
+
+   While additional whitespace is generally helpful for reading, do not
+use more than one blank line to separate blocks, and avoid adding
+whitespace after the end of a program line (as of 1/99, some 600 lines
+had whitespace after the semicolon).  Excess whitespace causes
+difficulties for diff and patch.
+
+Comments
+--------
+
+   The standard GNU requirements on comments must be followed strictly.
+
+   Block comments must appear in the following form, with no `/*'- or
+'*/'-only lines, and no leading `*':
+
+     /* Wait for control to return from inferior to debugger.  If inferior
+        gets a signal, we may decide to start it up again instead of
+        returning.  That is why there is a loop in this function.  When
+        this function actually returns it means the inferior should be left
+        stopped and GDB should read more commands.  */
+
+   (Note that this format is encouraged by Emacs; tabbing for a
+multi-line comment works correctly, and M-Q fills the block
+consistently.)
+
+   Put a blank line between the block comments preceding function or
+variable definitions, and the definition itself.
+
+   In general, put function-body comments on lines by themselves, rather
+than trying to fit them into the 20 characters left at the end of a
+line, since either the comment or the code will inevitably get longer
+than will fit, and then somebody will have to move it anyhow.
+
+C Usage
+-------
+
+   Code must not depend on the sizes of C data types, the format of the
+host's floating point numbers, the alignment of anything, or the order
+of evaluation of expressions.
+
+   Use functions freely.  There are only a handful of compute-bound
+areas in GDB that might be affected by the overhead of a function call,
+mainly in symbol reading.  Most of GDB's performance is limited by the
+target interface (whether serial line or system call).
+
+   However, use functions with moderation.  A thousand one-line
+functions are just as hard to understand as a single thousand-line
+function.
+
+Function Prototypes
+-------------------
+
+   Prototypes must be used to *declare* functions but never to *define*
+them.  Prototypes for GDB functions must include both the argument type
+and name, with the name matching that used in the actual function
+definition.
+
+   For the sake of compatibility with pre-ANSI compilers, define
+prototypes with the `PARAMS' macro:
+
+     extern int memory_remove_breakpoint PARAMS ((CORE_ADDR addr,
+                                                  char *contents_cache));
+
+   Note the double parentheses around the parameter types.  This allows
+an arbitrary number of parameters to be described, without freaking out
+the C preprocessor.  When the function has no parameters, it should be
+described like:
+
+     extern void noprocess PARAMS ((void));
+
+   The `PARAMS' macro expands to its argument in ANSI C, or to a simple
+`()' in traditional C.
+
+   All external functions should have a `PARAMS' declaration in a
+header file that callers include, except for `_initialize_*' functions,
+which must be external so that `init.c' construction works, but
+shouldn't be visible to random source files.
+
+   All static functions must be declared in a block near the top of the
+source file.
+
+Clean Design
+------------
+
+   In addition to getting the syntax right, there's the little question
+of semantics.  Some things are done in certain ways in GDB because long
+experience has shown that the more obvious ways caused various kinds of
+trouble.
+
+   You can't assume the byte order of anything that comes from a target
+(including VALUEs, object files, and instructions).  Such things must
+be byte-swapped using `SWAP_TARGET_AND_HOST' in GDB, or one of the swap
+routines defined in `bfd.h', such as `bfd_get_32'.
+
+   You can't assume that you know what interface is being used to talk
+to the target system.  All references to the target must go through the
+current `target_ops' vector.
+
+   You can't assume that the host and target machines are the same
+machine (except in the "native" support modules).  In particular, you
+can't assume that the target machine's header files will be available
+on the host machine.  Target code must bring along its own header files
+- written from scratch or explicitly donated by their owner, to avoid
+copyright problems.
+
+   Insertion of new `#ifdef''s will be frowned upon.  It's much better
+to write the code portably than to conditionalize it for various
+systems.
+
+   New `#ifdef''s which test for specific compilers or manufacturers or
+operating systems are unacceptable.  All `#ifdef''s should test for
+features.  The information about which configurations contain which
+features should be segregated into the configuration files.  Experience
+has proven far too often that a feature unique to one particular system
+often creeps into other systems; and that a conditional based on some
+predefined macro for your current system will become worthless over
+time, as new versions of your system come out that behave differently
+with regard to this feature.
+
+   Adding code that handles specific architectures, operating systems,
+target interfaces, or hosts, is not acceptable in generic code.  If a
+hook is needed at that point, invent a generic hook and define it for
+your configuration, with something like:
+
+     #ifdef	WRANGLE_SIGNALS
+        WRANGLE_SIGNALS (signo);
+     #endif
+
+   In your host, target, or native configuration file, as appropriate,
+define `WRANGLE_SIGNALS' to do the machine-dependent thing.  Take a bit
+of care in defining the hook, so that it can be used by other ports in
+the future, if they need a hook in the same place.
+
+   If the hook is not defined, the code should do whatever "most"
+machines want.  Using `#ifdef', as above, is the preferred way to do
+this, but sometimes that gets convoluted, in which case use
+
+     #ifndef SPECIAL_FOO_HANDLING
+     #define SPECIAL_FOO_HANDLING(pc, sp) (0)
+     #endif
+
+   where the macro is used or in an appropriate header file.
+
+   Whether to include a "small" hook, a hook around the exact pieces of
+code which are system-dependent, or whether to replace a whole function
+with a hook depends on the case.  A good example of this dilemma can be
+found in `get_saved_register'.  All machines that GDB 2.8 ran on just
+needed the `FRAME_FIND_SAVED_REGS' hook to find the saved registers.
+Then the SPARC and Pyramid came along, and `HAVE_REGISTER_WINDOWS' and
+`REGISTER_IN_WINDOW_P' were introduced.  Then the 29k and 88k required
+the `GET_SAVED_REGISTER' hook.  The first three are examples of small
+hooks; the latter replaces a whole function.  In this specific case, it
+is useful to have both kinds; it would be a bad idea to replace all the
+uses of the small hooks with `GET_SAVED_REGISTER', since that would
+result in much duplicated code.  Other times, duplicating a few lines
+of code here or there is much cleaner than introducing a large number
+of small hooks.
+
+   Another way to generalize GDB along a particular interface is with an
+attribute struct.  For example, GDB has been generalized to handle
+multiple kinds of remote interfaces - not by #ifdef's everywhere, but
+by defining the "target_ops" structure and having a current target (as
+well as a stack of targets below it, for memory references).  Whenever
+something needs to be done that depends on which remote interface we are
+using, a flag in the current target_ops structure is tested (e.g.
+`target_has_stack'), or a function is called through a pointer in the
+current target_ops structure.  In this way, when a new remote interface
+is added, only one module needs to be touched - the one that actually
+implements the new remote interface.  Other examples of
+attribute-structs are BFD access to multiple kinds of object file
+formats, or GDB's access to multiple source languages.
+
+   Please avoid duplicating code.  For example, in GDB 3.x all the code
+interfacing between `ptrace' and the rest of GDB was duplicated in
+`*-dep.c', and so changing something was very painful.  In GDB 4.x,
+these have all been consolidated into `infptrace.c'.  `infptrace.c' can
+deal with variations between systems the same way any
+system-independent file would (hooks, #if defined, etc.), and machines
+which are radically different don't need to use infptrace.c at all.
+