-GDB can produce warnings about symbols that it does not understand. By
-default, these warnings are disabled. You can enable them by executing
-`set complaint 10' (which you can put in your ~/.gdbinit if you like).
-I recommend doing this if you are working on a compiler, assembler,
-linker, or gdb, since it will point out problems that you may be able
-to fix. Warnings produced during symbol reading indicate some mismatch
-between the object file and GDB's symbol reading code (in many cases,
-it's a mismatch between the specs for the object file format, and what
-the compiler actually outputs or the debugger actually understands).
-
-If you port gdb to a new machine, please send the required changes
-to bug-gdb@prep.ai.mit.edu. If your changes are more than a few
-lines, obtain and send in a copyright assignment from gnu@prep.ai.mit.edu, as
-described in the section `Writing Code for GDB'.
-
-
- X Windows versus GDB
-
-xgdb is obsolete. We are not doing any development or support of it.
-
-There is an "xxgdb", which shows more promise, which was posted to
-comp.sources.x.
-
-For those intersted in auto display of source and the availability of
-an editor while debugging I suggest trying gdb-mode in gnu-emacs
-(Try typing M-x gdb RETURN). Comments on this mode are welcome.
-
-
- About the machine-dependent files
-
-tconfig/<machine>
-This contains Makefile stuff for when the target system is <machine>.
-It also specifies the name of the tm-XXX.h file for this machine.
-
-xconfig/<machine>
-This contains Makefile stuff for when the host system is <machine>.
-It also specifies the name of the xm-XXX.h file for this machine.
-
-tm-XXX.h (tm.h is a link to this file, created by configure).
-This file contains macro definitions about the target machine's
-registers, stack frame format and instructions.
-
-xm-XXX.h (xm.h is a link to this file, created by configure).
-This contains macro definitions describing the host system environment,
-such as byte order, host C compiler and library, ptrace support,
-and core file structure.
-
-<machine>-opcode.h
-<machine>-pinsn.c
-These files contain the information necessary to print instructions
-for your cpu type. <machine>-opcode.h includes some large initialized
-data structures, which is strange for a ".h" file, but it's OK since
-it is only included in one place. <machine>-opcode.h is shared
-between the debugger and the assembler (if the GNU assembler has been
-ported to that machine), whereas <machine>-pinsn.c is specific to GDB.
-
-<machine>-tdep.c
-This file contains any miscellaneous code required for this machine
-as a target. On some machines it doesn't exist at all. Its existence
-is specified in the tconfig/XXX file.
-
-<machine>-xdep.c
-This file contains any miscellaneous code required for this machine
-as a host. On some machines it doesn't exist at all. Its existence
-is specified in the xconfig/XXX file.
-
-infptrace.c
-This is the low level interface to inferior processes for systems
-using the Unix ptrace call in a vanilla way. Some systems have their
-own routines in <machine>-xdep.c. Whether or not it is used
-is specified in the xconfig/XXX file.
-
-coredep.c
-Machine and system-dependent aspects of reading core files. Some
-machines use coredep.c; some have the routines in <machine>-xdep.c.
-Whether or not it is used is specified in the xconfig/XXX file.
-Now that BFD is used to read core files, virtually all machines should
-use coredep.c and should just provide fetch_core_registers in
-<machine>-xdep.c.
-
-exec.c
-Machine and system-dependent aspects of reading executable files.
-Some machines use exec.c; some have the routines in <machine>-tdep.c
-Since BFD, virtually all machines should use exec.c.
-
-
- Writing Code for GDB
-
-We appreciate having users contribute code that is of general use, but
-for it to be included in future GDB releases it must be cleanly
-written. We do not want to include changes that will needlessly make
-future maintainance difficult. It is not much harder to do things
-right, and in the long term it is worth it to the GNU project, and
-probably to you individually as well.
-
-Please code according to the GNU coding standards. If you do not have
-a copy, you can request one by sending mail to gnu@prep.ai.mit.edu.
-
-If you make substantial changes, you'll have to file a copyright
-assignment with the Free Software Foundation before we can produce a
-release that includes your changes. Send mail requesting the copyright
-assignment to gnu@prep.ai.mit.edu. Do this early, like before the
-changes actually work, or even before you start them, because a manager
-or lawyer on your end will probably make this a slow process.
-
-Please try to avoid making machine-specific changes to
-machine-independent files. If this is unavoidable, put a hook in the
-machine-independent file which calls a (possibly) machine-dependent
-macro (for example, the IGNORE_SYMBOL macro can be used for any
-symbols which need to be ignored on a specific machine. Calling
-IGNORE_SYMBOL in dbxread.c is a lot cleaner than a maze of #if
-defined's). The machine-independent code should do whatever "most"
-machines want if the macro is not defined in param.h. Using #if
-defined can sometimes be OK (e.g. SET_STACK_LIMIT_HUGE) but should be
-conditionalized on a specific feature of an operating system (set in
-tm.h or xm.h) rather than something like #if defined(vax) or #if
-defined(SYSV). If you use an #ifdef on some symbol that is defined
-in a header file (e.g. #ifdef TIOCSETP), *please* make sure that you
-have #include'd the relevant header file in that module!
-
-It is better to replace entire routines which may be system-specific,
-rather than put in a whole bunch of hooks which are probably not going
-to be helpful for any purpose other than your changes. For example,
-if you want to modify dbxread.c to deal with DBX debugging symbols
-which are in COFF files rather than BSD a.out files, do something
-along the lines of a macro GET_NEXT_SYMBOL, which could have
-different definitions for COFF and a.out, rather than trying to put
-the necessary changes throughout all the code in dbxread.c that
-currently assumes BSD format.
-
-Please avoid duplicating code. For example, in GDB 3.x all the stuff
-in infptrace.c 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. The same was true of core_file_command
-and exec_file_command.
-
-
- Debugging gdb with itself
-
-If gdb is limping on your machine, this is the preferred way to get it
-fully functional. Be warned that in some ancient Unix systems, like
-Ultrix 4.0, a program can't be running in one process while it is being
-debugged in another. Rather than doing "./gdb ./gdb", which works on
-Suns and such, you can copy gdb to gdb2 and then do "./gdb ./gdb2".
-
-When you run gdb in this directory, it will read a ".gdbinit" file that
-sets up some simple things to make debugging gdb easier. The "info"
-command, when executed without a subcommand in a gdb being debugged by
-gdb, will pop you back up to the top level gdb. See .gdbinit for details.
-
-I strongly recommend printing out the reference card and using it.
-Send reference-card suggestions to bug-gdb@prep.ai.mit.edu, just like bugs.
-
-If you use emacs, you will probably want to do a "make TAGS" after you
-configure your distribution; this will put the machine dependent
-routines for your local machine where they will be accessed first by a
-M-period.
-
-Also, make sure that you've compiled gdb with your local cc or taken
-appropriate precautions regarding ansification of include files. See
-the Makefile for more information.