/*
* arch/cris/arch-v32/kernel/kgdb.c
*
* CRIS v32 version by Orjan Friberg, Axis Communications AB.
*
* S390 version
* Copyright (C) 1999 IBM Deutschland Entwicklung GmbH, IBM Corporation
* Author(s): Denis Joseph Barrow (djbarrow@de.ibm.com,barrow_dj@yahoo.com),
*
* Originally written by Glenn Engel, Lake Stevens Instrument Division
*
* Contributed by HP Systems
*
* Modified for SPARC by Stu Grossman, Cygnus Support.
*
* Modified for Linux/MIPS (and MIPS in general) by Andreas Busse
* Send complaints, suggestions etc. to <andy@waldorf-gmbh.de>
*
* Copyright (C) 1995 Andreas Busse
*/
/* FIXME: Check the documentation. */
/*
* kgdb usage notes:
* -----------------
*
* If you select CONFIG_ETRAX_KGDB in the configuration, the kernel will be
* built with different gcc flags: "-g" is added to get debug infos, and
* "-fomit-frame-pointer" is omitted to make debugging easier. Since the
* resulting kernel will be quite big (approx. > 7 MB), it will be stripped
* before compresion. Such a kernel will behave just as usually, except if
* given a "debug=<device>" command line option. (Only serial devices are
* allowed for <device>, i.e. no printers or the like; possible values are
* machine depedend and are the same as for the usual debug device, the one
* for logging kernel messages.) If that option is given and the device can be
* initialized, the kernel will connect to the remote gdb in trap_init(). The
* serial parameters are fixed to 8N1 and 115200 bps, for easyness of
* implementation.
*
* To start a debugging session, start that gdb with the debugging kernel
* image (the one with the symbols, vmlinux.debug) named on the command line.
* This file will be used by gdb to get symbol and debugging infos about the
* kernel. Next, select remote debug mode by
* target remote <device>
* where <device> is the name of the serial device over which the debugged
* machine is connected. Maybe you have to adjust the baud rate by
* set remotebaud <rate>
* or also other parameters with stty:
* shell stty ... </dev/...
* If the kernel to debug has already booted, it waited for gdb and now
* connects, and you'll see a breakpoint being reported. If the kernel isn't
* running yet, start it now. The order of gdb and the kernel doesn't matter.
| 