180 строки
7.6 KiB
Plaintext
180 строки
7.6 KiB
Plaintext
|
|
This file describes the configuration and behavior of KGDB for the SH
|
|
kernel. Based on a description from Henry Bell <henry.bell@st.com>, it
|
|
has been modified to account for quirks in the current implementation.
|
|
|
|
Version
|
|
=======
|
|
|
|
This version of KGDB was written for 2.4.xx kernels for the SH architecture.
|
|
Further documentation is available from the linux-sh project website.
|
|
|
|
|
|
Debugging Setup: Host
|
|
======================
|
|
|
|
The two machines will be connected together via a serial line - this
|
|
should be a null modem cable i.e. with a twist.
|
|
|
|
On your DEVELOPMENT machine, go to your kernel source directory and
|
|
build the kernel, enabling KGDB support in the "kernel hacking" section.
|
|
This includes the KGDB code, and also makes the kernel be compiled with
|
|
the "-g" option set -- necessary for debugging.
|
|
|
|
To install this new kernel, use the following installation procedure.
|
|
|
|
Decide on which tty port you want the machines to communicate, then
|
|
cable them up back-to-back using the null modem. On the DEVELOPMENT
|
|
machine, you may wish to create an initialization file called .gdbinit
|
|
(in the kernel source directory or in your home directory) to execute
|
|
commonly-used commands at startup.
|
|
|
|
A minimal .gdbinit might look like this:
|
|
|
|
file vmlinux
|
|
set remotebaud 115200
|
|
target remote /dev/ttyS0
|
|
|
|
Change the "target" definition so that it specifies the tty port that
|
|
you intend to use. Change the "remotebaud" definition to match the
|
|
data rate that you are going to use for the com line (115200 is the
|
|
default).
|
|
|
|
Debugging Setup: Target
|
|
========================
|
|
|
|
By default, the KGDB stub will communicate with the host GDB using
|
|
ttySC1 at 115200 baud, 8 databits, no parity; these defaults can be
|
|
changed in the kernel configuration. As the kernel starts up, KGDB will
|
|
initialize so that breakpoints, kernel segfaults, and so forth will
|
|
generally enter the debugger.
|
|
|
|
This behavior can be modified by including the "kgdb" option in the
|
|
kernel command line; this option has the general form:
|
|
|
|
kgdb=<ttyspec>,<action>
|
|
|
|
The <ttyspec> indicates the port to use, and can optionally specify
|
|
baud, parity and databits -- e.g. "ttySC0,9600N8" or "ttySC1,19200".
|
|
|
|
The <action> can be "halt" or "disabled". The "halt" action enters the
|
|
debugger via a breakpoint as soon as kgdb is initialized; the "disabled"
|
|
action causes kgdb to ignore kernel segfaults and such until explicitly
|
|
entered by a breakpoint in the code or by external action (sysrq or NMI).
|
|
|
|
(Both <ttyspec> and <action> can appear alone, w/o the separating comma.)
|
|
|
|
For example, if you wish to debug early in kernel startup code, you
|
|
might specify the halt option:
|
|
|
|
kgdb=halt
|
|
|
|
Boot the TARGET machinem, which will appear to hang.
|
|
|
|
On your DEVELOPMENT machine, cd to the source directory and run the gdb
|
|
program. (This is likely to be a cross GDB which runs on your host but
|
|
is built for an SH target.) If everything is working correctly you
|
|
should see gdb print out a few lines indicating that a breakpoint has
|
|
been taken. It will actually show a line of code in the target kernel
|
|
inside the gdbstub activation code.
|
|
|
|
NOTE: BE SURE TO TERMINATE OR SUSPEND any other host application which
|
|
may be using the same serial port (for example, a terminal emulator you
|
|
have been using to connect to the target boot code.) Otherwise, data
|
|
from the target may not all get to GDB!
|
|
|
|
You can now use whatever gdb commands you like to set breakpoints.
|
|
Enter "continue" to start your target machine executing again. At this
|
|
point the target system will run at full speed until it encounters
|
|
your breakpoint or gets a segment violation in the kernel, or whatever.
|
|
|
|
Serial Ports: KGDB, Console
|
|
============================
|
|
|
|
This version of KGDB may not gracefully handle conflict with other
|
|
drivers in the kernel using the same port. If KGDB is configured on the
|
|
same port (and with the same parameters) as the kernel console, or if
|
|
CONFIG_SH_KGDB_CONSOLE is configured, things should be fine (though in
|
|
some cases console messages may appear twice through GDB). But if the
|
|
KGDB port is not the kernel console and used by another serial driver
|
|
which assumes different serial parameters (e.g. baud rate) KGDB may not
|
|
recover.
|
|
|
|
Also, when KGDB is entered via sysrq-g (requires CONFIG_KGDB_SYSRQ) and
|
|
the kgdb port uses the same port as the console, detaching GDB will not
|
|
restore the console to working order without the port being re-opened.
|
|
|
|
Another serious consequence of this is that GDB currently CANNOT break
|
|
into KGDB externally (e.g. via ^C or <BREAK>); unless a breakpoint or
|
|
error is encountered, the only way to enter KGDB after the initial halt
|
|
(see above) is via NMI (CONFIG_KGDB_NMI) or sysrq-g (CONFIG_KGDB_SYSRQ).
|
|
|
|
Code is included for the basic Hitachi Solution Engine boards to allow
|
|
the use of ttyS0 for KGDB if desired; this is less robust, but may be
|
|
useful in some cases. (This cannot be selected using the config file,
|
|
but only through the kernel command line, e.g. "kgdb=ttyS0", though the
|
|
configured defaults for baud rate etc. still apply if not overridden.)
|
|
|
|
If gdbstub Does Not Work
|
|
========================
|
|
|
|
If it doesn't work, you will have to troubleshoot it. Do the easy
|
|
things first like double checking your cabling and data rates. You
|
|
might try some non-kernel based programs to see if the back-to-back
|
|
connection works properly. Just something simple like cat /etc/hosts
|
|
/dev/ttyS0 on one machine and cat /dev/ttyS0 on the other will tell you
|
|
if you can send data from one machine to the other. There is no point
|
|
in tearing out your hair in the kernel if the line doesn't work.
|
|
|
|
If you need to debug the GDB/KGDB communication itself, the gdb commands
|
|
"set debug remote 1" and "set debug serial 1" may be useful, but be
|
|
warned: they produce a lot of output.
|
|
|
|
Threads
|
|
=======
|
|
|
|
Each process in a target machine is seen as a gdb thread. gdb thread related
|
|
commands (info threads, thread n) can be used. CONFIG_KGDB_THREAD must
|
|
be defined for this to work.
|
|
|
|
In this version, kgdb reports PID_MAX (32768) as the process ID for the
|
|
idle process (pid 0), since GDB does not accept 0 as an ID.
|
|
|
|
Detaching (exiting KGDB)
|
|
=========================
|
|
|
|
There are two ways to resume full-speed target execution: "continue" and
|
|
"detach". With "continue", GDB inserts any specified breakpoints in the
|
|
target code and resumes execution; the target is still in "gdb mode".
|
|
If a breakpoint or other debug event (e.g. NMI) happens, the target
|
|
halts and communicates with GDB again, which is waiting for it.
|
|
|
|
With "detach", GDB does *not* insert any breakpoints; target execution
|
|
is resumed and GDB stops communicating (does not wait for the target).
|
|
In this case, the target is no longer in "gdb mode" -- for example,
|
|
console messages no longer get sent separately to the KGDB port, or
|
|
encapsulated for GDB. If a debug event (e.g. NMI) occurs, the target
|
|
will re-enter "gdb mode" and will display this fact on the console; you
|
|
must give a new "target remote" command to gdb.
|
|
|
|
NOTE: TO AVOID LOSSING CONSOLE MESSAGES IN CASE THE KERNEL CONSOLE AND
|
|
KGDB USING THE SAME PORT, THE TARGET WAITS FOR ANY INPUT CHARACTER ON
|
|
THE KGDB PORT AFTER A DETACH COMMAND. For example, after the detach you
|
|
could start a terminal emulator on the same host port and enter a <cr>;
|
|
however, this program must then be terminated or suspended in order to
|
|
use GBD again if KGDB is re-entered.
|
|
|
|
|
|
Acknowledgements
|
|
================
|
|
|
|
This code was mostly generated by Henry Bell <henry.bell@st.com>;
|
|
largely from KGDB by Amit S. Kale <akale@veritas.com> - extracts from
|
|
code by Glenn Engel, Jim Kingdon, David Grothe <dave@gcom.com>, Tigran
|
|
Aivazian <tigran@sco.com>, William Gatliff <bgat@open-widgets.com>, Ben
|
|
Lee, Steve Chamberlain and Benoit Miller <fulg@iname.com> are also
|
|
included.
|
|
|
|
Jeremy Siegel
|
|
<jsiegel@mvista.com>
|