To prepare a kernel for testing, apply a KGDB patch to a linux kernel source. Then enable Remote (serial) kernel debugging with GDB from kernel hacking, which will enable KGDB code in the kernel.This will enable choice of a few more config options with change KGDB behavior. These are described below.

Thread analysis: With thread analysis enabled, gdb can talk to kgdb stub to list threads and to get stack trace for a thread. This option also enables
 some code which helps gdb get exact status of thread. Thread analysis adds some overhead to schedule and down functions. You can disable this   option if you do not want to compromise on execution speed.

Console messages through GDB: With this option enabled, kgdb stub will route console messages through GDB. Console messages from the test machine will appear in a terminal on the development machine where gdb is running. Other consoles will not be affected by this option.

Enable kernel asserts:  This option has been removed from KGDB versions 2.0 onwards.  This option enables kernel asserts. A kernel assert is a condition, which if turnes out to be false during an execution path, then KGDB is called. Kernel assertions help in modifying the kernel or writing drivers. Bugs can be traced sooner with kernel asserts because invalid   conditions caused by bugs are checked at various places. Kernel asserts add the overhead of checking asserted conditions. You can disable this option if you do not want the overhead.

After the kernel is configured, build it and and add it to Grub. KGDB stub requires following options in a kernel command line.
 kgdbwait: This option causes KGDB to wait for a GDB connection during kernel bootup.
 kgdb8250=<port number>,<port speed>
 Where port number can be 0 to 3 for ports ttyS0(COM1) to ttyS3(COM4) respectively.Supported port speeds are 9600, 19200, 38400, 57600 and 115200.

Options for KGDB versions prior to version 2.0 are as follows
 gdb:   The kernel should wait at startup for gdb to connect.
 gdbttyS=:  This option tells kgdb stub which serial line to use. 0 to 3 numbers given here correspond to ttyS0 to ttyS3 respectively. ttyS0 is COM1 port ttyS1 is COM2 port and so on.
 gdbbaud=: baud rate should be used on the serial line. This should be between 9600 to 115200.

An example of above procedure is shown below
 On development machine:
1. Extract a kernel source
 $ cd /mnt/work/build/old-pc
 $ bunzip2 -c ~/linux-2.4.6.tar.bz2 | tar xvf -
 $ mv linux linux-2.4.6-kgdb
2. Apply kgdb patch Versions 2.0 onwards have multiple kgdb patches.
 $ cd linux-2.4.6-kgdb
 $ patch -p1 < ~/linux-2.4.6-kgdb.patch
3. Configure the kernel
 $ make xconfig or make menuconfig
Configure drivers and other kernel options
To enable kgdb, enable following config options (in this order).
 Kernel hacking ->
     KGDB: kernel debugging with remote gdb ->
         KGDB: Thread analysis
         KGDB: Console messages through gdb
 Device drivers ->
     Character devices ->
         Serial drivers ->
             KGDB: On generic serial port (8250)
For kernel versions prior to kgdb 2.0.1:
 Goto "kernel hacking"
 Enable "Remote (serial) kernel debugging with gdb"
  This will enable debugging support in the kernel.
 (Optional) Enable "Console messages through gdb (NEW)"
4. Build the kernel
 $ make dep
 $ make bzImage
5. Copy the kernel to target machine
It is assumed that the user who is working on the development machine has rsh permissions on the test machine for root account.
$ rcp System.map testmach:/boot/System.map-2.4.6-kgdb
$ rcp arch/i386/boot/bzImage testmach:/boot/vmlinuz-2.4.6-kgdb


On test machine:
6. Add a grub entry:
 title 2.6.0 kgdb
         root (hd0,0)
         kernel /boot/vmlinuz-2.6.0 ro root=/dev/hda1 rootfstype=ext3 kgdbwait kgdb8250=1,57600
An example lilo entry for kgdb versions prior to 2.0 is shown below.
 image=/boot/vmlinuz-2.4.6
         label=kgdb
         read-only
         root=/dev/hda3
         append="gdb gdbttyS=1 gdbbaud=115200"

Modules in the test machine:
It is recommended that you compile all drivers in the kernel itself instead of compiling them as a module. This is because modules cannot be debugged without loading them using loadmodule.sh script. (Please refer to loading a module in a test machine for details.) If a module has to be loaded, please load it with loadmodule.sh script.