This page was produced by an automated import process, and may have formatting errors; feel free to fix.
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 gdb-gdb.gdb file (plus possibly gdb-gdb.py 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 gdb-gdb.gdb 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.