21 May, 2010
15 commits
-
The kernel debugger can operate well before mm_init(), but the x86
hardware breakpoint code which uses the perf api requires that the
kernel allocators are initialized.This means the kernel debug core needs to provide an optional arch
specific call back to allow the initialization functions to run after
the kernel has been further initialized.The kdb shell already had a similar restriction with an early
initialization and late initialization. The kdb_init() was moved into
the debug core's version of the late init which is called
dbg_late_init();CC: kgdb-bugreport@lists.sourceforge.net
Signed-off-by: Jason Wessel -
It is highly desirable to trap into kdb on panic. The debug core will
attempt to register as the first in line for the panic notifier.CC: Ingo Molnar
CC: Andrew Morton
CC: Eric W. Biederman
Signed-off-by: Jason Wessel -
This allows kdb to debug a crash with in the kms code with a
single level recursive re-entry.Signed-off-by: Jason Wessel
-
Certain calls from the kdb shell will call out to printk(), and any of
these calls should get vectored back to the kdb_printf() so that the
kdb pager and processing can be used, as well as to properly channel
I/O to the polled I/O devices.CC: Randy Dunlap
Signed-off-by: Jason Wessel
Acked-by: Andrew Morton -
If kdb is open on a serial port that is not actually a console make
sure to call the poll routines to emit and receive characters.Signed-off-by: Jason Wessel
Acked-by: Martin Hicks -
Some kgdb I/O modules require the ability to create a breakpoint
tasklet, such as kgdboc and external modules such as kgdboe. The
breakpoint tasklet is used as an asynchronous entry point into the
debugger which will have a different function scope than the current
execution path where it might not be safe to have an inline
breakpoint. This is true of some of the kgdb I/O drivers which share
code with kgdb and rest of the kernel users.Signed-off-by: Jason Wessel
-
The only way the debugger can handle a trap in inside rcu_lock,
notify_die, or atomic_notifier_call_chain without a triple fault is
to have a low level "first opportunity handler" in the int3 exception
handler.Generally this will be something the vast majority of folks will not
need, but for those who need it, it is added as a kernel .config
option called KGDB_LOW_LEVEL_TRAP.CC: Ingo Molnar
CC: Thomas Gleixner
CC: H. Peter Anvin
CC: x86@kernel.org
Signed-off-by: Jason Wessel -
Remove all the references to the kgdb_post_primary_code. This
function serves no useful purpose because you can obtain the same
information from the "struct kgdb_state *ks" from with in the
debugger, if for some reason you want the data.Also remove the unintentional duplicate assignment for ks->ex_vector.
Signed-off-by: Jason Wessel
-
This patch adds in the kdb PS/2 keyboard driver. This was mostly a
direct port from the original kdb where I cleaned up the code against
checkpatch.pl and added the glue to stitch it into kgdb.This patch also enables early kdb debug via kgdbwait and the keyboard.
All the access to configure kdb using either a serial console or the
keyboard is done via kgdboc.If you want to use only the keyboard and want to break in early you
would add to your kernel command arguments:kgdboc=kbd kgdbwait
If you wanted serial and or the keyboard access you could use:
kgdboc=kbd,ttyS0
You can also configure kgdboc as a kernel module or at run time with
the sysfs where you can activate and deactivate kgdb.Turn it on:
echo kbd,ttyS0 > /sys/module/kgdboc/parameters/kgdbocTurn it off:
echo "" > /sys/module/kgdboc/parameters/kgdbocSigned-off-by: Jason Wessel
Reviewed-by: Dmitry Torokhov -
One of the driving forces behind integrating another front end (kdb)
to the debug core is to allow front end commands to be accessible via
gdb's monitor command. It is true that you could write gdb macros to
get certain data, but you may want to just use gdb to access the
commands that are available in the kdb front end.This patch implements the Rcmd gdb stub packet. In gdb you access
this with the "monitor" command. For instance you could type "monitor
help", "monitor lsmod" or "monitor ps A" etc...There is no error checking or command restrictions on what you can and
cannot access at this point. Doing something like trying to set
breakpoints with the monitor command is going to cause nothing but
problems. Perhaps in the future only the commands that are actually
known to work with the gdb monitor command will be available.Signed-off-by: Jason Wessel
-
The design of the kdb shell requires that every device that can
provide input to kdb have a polling routine that exits immediately if
there is no character available. This is required in order to get the
page scrolling mechanism working.Changing the kernel debugger I/O API to require all polling character
routines to exit immediately if there is no data allows the kernel
debugger to process multiple input channels.NO_POLL_CHAR will be the return code to the polling routine when ever
there is no character available.CC: linux-serial@vger.kernel.org
Signed-off-by: Jason Wessel -
These are the minimum changes to the kgdb core in order to enable an
API to connect a new front end (kdb) to the debug core.This patch introduces the dbg_kdb_mode variable controls where the
user level I/O is routed. It will be routed to the gdbstub (kgdb) or
to the kdb front end which is a simple shell available over the kgdboc
connection.You can switch back and forth between kdb or the gdb stub mode of
operation dynamically. From gdb stub mode you can blindly type
"$3#33", or from the kdb mode you can enter "kgdb" to switch to the
gdb stub.The logic in the debug core depends on kdb to look for the typical gdb
connection sequences and return immediately with KGDB_PASS_EVENT if a
gdb serial command sequence is detected. That should allow a
reasonably seamless transition between kdb -> gdb without leaving the
kernel exception state. The two gdb serial queries that kdb is
responsible for detecting are the "?" and "qSupported" packets.CC: Ingo Molnar
Signed-off-by: Jason Wessel
Acked-by: Martin Hicks -
This patch contains only the kdb core. Because the change set was
large, it was split. The next patch in the series includes the
instrumentation into the core kernel which are mainly helper functions
for kdb.This work is directly derived from kdb v4.4 found at:
ftp://oss.sgi.com/projects/kdb/download/v4.4/
The kdb internals have been re-organized to make them mostly platform
independent and to connect everything to the debug core which is used by
gdbstub (which has long been known as kgdb).The original version of kdb was 58,000 lines worth of changes to
support x86. From that implementation only the kdb shell, and basic
commands for memory access, runcontrol, lsmod, and dmesg where carried
forward.This is a generic implementation which aims to cover all the current
architectures using the kgdb core: ppc, arm, x86, mips, sparc, sh and
blackfin. More archictectures can be added by implementing the
architecture specific kgdb functions.[mort@sgi.com: Compile fix with hugepages enabled]
[mort@sgi.com: Clean breakpoint code renaming kdba_ -> kdb_]
[mort@sgi.com: fix new line after printing registers]
[mort@sgi.com: Remove the concept of global vs. local breakpoints]
[mort@sgi.com: Rework kdb_si_swapinfo to use more generic name]
[mort@sgi.com: fix the information dump macros, remove 'arch' from the names]
[sfr@canb.auug.org.au: include fixup to include linux/slab.h]CC: linux-arch@vger.kernel.org
Signed-off-by: Jason Wessel
Signed-off-by: Martin Hicks -
Split the former kernel/kgdb.c into debug_core.c which contains the
kernel debugger exception logic and to the gdbstub.c which contains
the logic for allowing gdb to talk to the debug core.This also created a private include file called debug_core.h which
contains all the definitions to glue the debug_core to any other
debugger connections.CC: Ingo Molnar
Signed-off-by: Jason Wessel -
Move kgdb.c in preparation to separate the gdbstub from the debug
core and exception handling.CC: Ingo Molnar
Signed-off-by: Jason Wessel
