GNU Info
(gdbint.info)Debugging GDB
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.2, a program can't be running in one process while it is being
debugged in another. Rather than typing the command `./gdb ./gdb',
which works on Suns and such, you can copy `gdb' to `gdb2' and then
type `./gdb ./gdb2'.
When you run GDB in the GDB source 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.
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
`M-.'
Also, make sure that you've either compiled GDB with your local cc,
or have run `fixincludes' if you are compiling with gcc.
Submitting Patches
==================
Thanks for thinking of offering your changes back to the community of
GDB users. In general we like to get well designed enhancements.
Thanks also for checking in advance about the best way to transfer the
changes.
The GDB maintainers will only install "cleanly designed" patches.
This manual summarizes what we believe to be clean design for GDB.
If the maintainers don't have time to put the patch in when it
arrives, or if there is any question about a patch, it goes into a
large queue with everyone else's patches and bug reports.
The legal issue is that to incorporate substantial changes requires a
copyright assignment from you and/or your employer, granting ownership
of the changes to the Free Software Foundation. You can get the
standard documents for doing this by sending mail to `gnu@gnu.org' and
asking for it. We recommend that people write in "All programs owned
by the Free Software Foundation" as "NAME OF PROGRAM", so that changes
in many programs (not just GDB, but GAS, Emacs, GCC, etc) can be
contributed with only one piece of legalese pushed through the
bureaucracy and filed with the FSF. We can't start merging changes
until this paperwork is received by the FSF (their rules, which we
follow since we maintain it for them).
Technically, the easiest way to receive changes is to receive each
feature as a small context diff or unidiff, suitable for `patch'. Each
message sent to me should include the changes to C code and header
files for a single feature, plus `ChangeLog' entries for each directory
where files were modified, and diffs for any changes needed to the
manuals (`gdb/doc/gdb.texinfo' or `gdb/doc/gdbint.texinfo'). If there
are a lot of changes for a single feature, they can be split down into
multiple messages.
In this way, if we read and like the feature, we can add it to the
sources with a single patch command, do some testing, and check it in.
If you leave out the `ChangeLog', we have to write one. If you leave
out the doc, we have to puzzle out what needs documenting. Etc., etc.
The reason to send each change in a separate message is that we will
not install some of the changes. They'll be returned to you with
questions or comments. If we're doing our job correctly, the message
back to you will say what you have to fix in order to make the change
acceptable. The reason to have separate messages for separate features
is so that the acceptable changes can be installed while one or more
changes are being reworked. If multiple features are sent in a single
message, we tend to not put in the effort to sort out the acceptable
changes from the unacceptable, so none of the features get installed
until all are acceptable.
If this sounds painful or authoritarian, well, it is. But we get a
lot of bug reports and a lot of patches, and many of them don't get
installed because we don't have the time to finish the job that the bug
reporter or the contributor could have done. Patches that arrive
complete, working, and well designed, tend to get installed on the day
they arrive. The others go into a queue and get installed as time
permits, which, since the maintainers have many demands to meet, may not
be for quite some time.
Please send patches directly to the GDB maintainers
<gdb-patches@sources.redhat.com>.
Obsolete Conditionals
=====================
Fragments of old code in GDB sometimes reference or set the following
configuration macros. They should not be used by new code, and old uses
should be removed as those parts of the debugger are otherwise touched.
`STACK_END_ADDR'
This macro used to define where the end of the stack appeared, for
use in interpreting core file formats that don't record this
address in the core file itself. This information is now
configured in BFD, and GDB gets the info portably from there. The
values in GDB's configuration files should be moved into BFD
configuration files (if needed there), and deleted from all of
GDB's config files.
Any `FOO-xdep.c' file that references STACK_END_ADDR is so old
that it has never been converted to use BFD. Now that's old!
`PYRAMID_CONTROL_FRAME_DEBUGGING'
pyr-xdep.c
`PYRAMID_CORE'
pyr-xdep.c
`PYRAMID_PTRACE'
pyr-xdep.c
`REG_STACK_SEGMENT'
exec.c
automatically generated by info2www version 1.2.2.9