/*!**************************************************************************
*!
*! FILE NAME : kgdb.c
*!
*! DESCRIPTION: Implementation of the gdb stub with respect to ETRAX 100.
*! It is a mix of arch/m68k/kernel/kgdb.c and cris_stub.c.
*!
*!---------------------------------------------------------------------------
*! HISTORY
*!
*! DATE NAME CHANGES
*! ---- ---- -------
*! Apr 26 1999 Hendrik Ruijter Initial version.
*! May 6 1999 Hendrik Ruijter Removed call to strlen in libc and removed
*! struct assignment as it generates calls to
*! memcpy in libc.
*! Jun 17 1999 Hendrik Ruijter Added gdb 4.18 support. 'X', 'qC' and 'qL'.
*! Jul 21 1999 Bjorn Wesen eLinux port
*!
*!---------------------------------------------------------------------------
*!
*! (C) Copyright 1999, Axis Communications AB, LUND, SWEDEN
*!
*!**************************************************************************/
/* @(#) cris_stub.c 1.3 06/17/99 */
/*
* 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.
* Another thing worth knowing about in the getting-started phase is how to
* debug the remote protocol itself. This is activated with
* set remotedebug 1
* gdb will then print out each packet sent or received. You'll also get some
* messages about the gdb stub on the console of the debugged machine.
*
* If all that works, you can use lots of the usual debugging techniques on
* the kernel, e.g. inspecting and changing variables/memory, setting
* breakpoints, single stepping and so on. It's also possible to interrupt the
* debugged kernel by pressing C-c in gdb. Have fun! :-)
*
* The gdb stub is entered (and thus the re
