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
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
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
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
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
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
/boot/vmlinuz-2.6.0 ro root=/dev/hda1 rootfstype=ext3 kgdbwait
An example lilo entry for kgdb versions prior to 2.0 is shown below.
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.