sh: Kill off remaining CONFIG_SH_KGDB bits.
Now that we use the generic stub, kill off all of the left over references. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This commit is contained in:
Paul Mundt
parent
07d2a1a1cd
commit
776d6c298a
2 changed files with 0 additions and 180 deletions
|
|
@ -1,179 +0,0 @@
|
|||
|
||||
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 machine, 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>
|
||||
|
|
@ -9,7 +9,6 @@ obj-$(CONFIG_VSYSCALL) += vsyscall/
|
|||
obj-$(CONFIG_SMP) += smp.o
|
||||
obj-$(CONFIG_CF_ENABLER) += cf-enabler.o
|
||||
obj-$(CONFIG_SH_STANDARD_BIOS) += sh_bios.o
|
||||
obj-$(CONFIG_SH_KGDB) += kgdb_stub.o kgdb_jmp.o
|
||||
obj-$(CONFIG_SH_CPU_FREQ) += cpufreq.o
|
||||
obj-$(CONFIG_MODULES) += sh_ksyms_64.o module.o
|
||||
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
|
||||
|
|
|
|||
Loading…
Reference in a new issue