kgdb is a source level debugger for linux kernel. It is used along
with gdb to debug a linux kernel. The expectation is that gdb can
be used to "break in" to the kernel to inspect memory, variables
- and look through a cal stack information similar to what an
+ and look through call stack information similar to what an
application developer would use gdb for. It is possible to place
breakpoints in kernel code and perform some limited execution
stepping.
runs an instance of gdb against the vmlinux file which contains
the symbols (not boot image such as bzImage, zImage, uImage...).
In gdb the developer specifies the connection parameters and
- connects to kgdb. Depending on which kgdb I/O modules exist in
- the kernel for a given architecture, it may be possible to debug
- the test machine's kernel with the development machine using a
- rs232 or ethernet connection.
+ connects to kgdb. The type of connection a developer makes with
+ gdb depends on the availability of kgdb I/O modules compiled as
+ builtin's or kernel modules in the test machine's kernel.
</para>
</chapter>
<chapter id="CompilingAKernel">
<title>Compiling a kernel</title>
<para>
- To enable <symbol>CONFIG_KGDB</symbol>, look under the "Kernel debugging"
- and then select "KGDB: kernel debugging with remote gdb".
+ To enable <symbol>CONFIG_KGDB</symbol> you should first turn on
+ "Prompt for development and/or incomplete code/drivers"
+ (CONFIG_EXPERIMENTAL) in "General setup", then under the
+ "Kernel debugging" select "KGDB: kernel debugging with remote gdb".
+ </para>
+ <para>
+ It is advised, but not required that you turn on the
+ CONFIG_FRAME_POINTER kernel option. This option inserts code to
+ into the compiled executable which saves the frame information in
+ registers or on the stack at different points which will allow a
+ debugger such as gdb to more accurately construct stack back traces
+ while debugging the kernel.
+ </para>
+ <para>
+ If the architecture that you are using supports the kernel option
+ CONFIG_DEBUG_RODATA, you should consider turning it off. This
+ option will prevent the use of software breakpoints because it
+ marks certain regions of the kernel's memory space as read-only.
+ If kgdb supports it for the architecture you are using, you can
+ use hardware breakpoints if you desire to run with the
+ CONFIG_DEBUG_RODATA option turned on, else you need to turn off
+ this option.
</para>
<para>
Next you should choose one of more I/O drivers to interconnect debugging
</para>
<para>
IMPORTANT NOTE: Using this option with kgdb over the console
- (kgdboc) or kgdb over ethernet (kgdboe) is not supported.
+ (kgdboc) is not supported.
</para>
</sect1>
</chapter>
(gdb) target remote /dev/ttyS0
</programlisting>
<para>
- Example (kgdb to a terminal server):
- </para>
- <programlisting>
- % gdb ./vmlinux
- (gdb) target remote udp:192.168.2.2:6443
- </programlisting>
- <para>
- Example (kgdb over ethernet):
+ Example (kgdb to a terminal server on tcp port 2012):
</para>
<programlisting>
% gdb ./vmlinux
- (gdb) target remote udp:192.168.2.2:6443
+ (gdb) target remote 192.168.2.2:2012
</programlisting>
<para>
Once connected, you can debug a kernel the way you would debug an
seriously wrong while debugging, it will most often be the case
that you want to enable gdb to be verbose about its target
communications. You do this prior to issuing the <constant>target
- remote</constant> command by typing in: <constant>set remote debug 1</constant>
+ remote</constant> command by typing in: <constant>set debug remote 1</constant>
</para>
</chapter>
<chapter id="KGDBTestSuite">
git://ftp.safe.ca / safe / jmp / linux-2.6 / blobdiff