Usage of GDB kernel debugging is similar to that for debugging
application processes. These webpages briefly describe gdb commands and
kernel issues related to these commands. Most of the kernel issues are
related to inline functions used in the kernel. KGDB supports GDB
execution control commands, stack trace and thread analysis. It doesn't
support GDB watchpoints. kgdb watchpoints are accessed through GDB
macros. Use of these macros is also described in these webpages.
Please refer to GDB documenation for a list of GDB commands and
explanations of their usage. GDB documenation can be accessed by the
GDB has online help also. The GDB command help gives a short
description of a command name or topic name given as an argument.
Killing or terminating GDB
If GDB does not respond to user input, you can kill it. If the test
kernel was controlled by kgdb when gdb was killed, a new GDB can be
started and it can be connected to kgdb. Otherwise you'll first need to
make the test kernel drop into kgdb. To do this send an ascii 3
character into the serial line. An example of a command which does that
echo -e "\003" > /dev/ttyS1
When GDB has printed a command prompt, you can quit it and start a new
GDB and connect to KGDB immediately.
GDB removes all breakpoints before presenting a command prompt.
Hence if a new GDB is started, there will be no breakpoints in the
kernel. You'll need to add all the breakpoints again. However, if a
running GDB was killed after adding some breakpoints, they will remain
in the kernel. New GDB will not know about those breakpoints. Hence if
one of these breakpoints is hit during subsequent execution, GDB will
not be able to handle it properly. Since a breakpoint modifies code,
execution after this point is unpredictable. A hardware reset is
recommended in this case. KGDB versions 1.6 onwards maintain breakpoints
within the stub itself, hence don't show this problem.
KGDB hardware watchpoints are handled by KGDB stub and GDB does not
know anything about them. Hence there are no issues with watchpoints
if a GDB is killed.
Test machine reboot
If a machine is rebooted, it is recommended that you terminate or kill
GDB before the debug kernel starts again. If that is not done and kgdb
will connect GDB. If some breakpoints were added in previous execution
of the kernel, GDB will try to remove them on connection. Since the
breakpoints will be absent in new execution of the kernel, the result