There is no technical reason that the kgdb core requires frame
pointers. It is up to the end user of KGDB to decide if they need
them or not.
[ anemo@mba.ocn.ne.jp: removed frame pointers on mips ]
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Remove HAVE_ARCH_KGDB_SHADOW_INFO because it does not
exist anywhere in the kernel mainline sources
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
This patch adds in the ability to compile the kgdb internal test
string into the kernel so as to run the tests at boot without changing
the kernel boot arguments. This patch also changes all the error
paths to invoke WARN_ON(1) which will emit the line number of the file
and dump the kernel stack when an error occurs.
You can disable the tests in a kernel that is built this way
using "kgdbts="
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This patch adds regression tests for testing the kgdb core and arch
specific implementation.
The kgdb test suite is designed to be built into the kernel and not as
a module because it uses a number of low level kernel and kgdb
primitives which should not be exported externally.
The kgdb test suite is designed as a KGDB I/O module which
simulates the communications that a debugger would have with kgdb.
The tests are broken up in to a line by line and referenced here as
a "get" which is kgdb requesting input and "put" which is kgdb
sending a response.
The kgdb suite can be invoked from the kernel command line
arguments system or executed dynamically at run time. The test
suite uses the variable "kgdbts" to obtain the information about
which tests to run and to configure the verbosity level. The
following are the various characters you can use with the kgdbts=
line:
When using the "kgdbts=" you only choose one of the following core
test types:
A = Run all the core tests silently
V1 = Run all the core tests with minimal output
V2 = Run all the core tests in debug mode
You can also specify optional tests:
N## = Go to sleep with interrupts of for ## seconds
to test the HW NMI watchdog
F## = Break at do_fork for ## iterations
S## = Break at sys_open for ## iterations
NOTE: that the do_fork and sys_open tests are mutually exclusive.
To invoke the kgdb test suite from boot you use a kernel start
argument as follows:
kgdbts=V1 kgdbwait
Or if you wanted to perform the NMI test for 6 seconds and do_fork
test for 100 forks, you could use:
kgdbts=V1N6F100 kgdbwait
The test suite can also be invoked at run time with:
echo kgdbts=V1N6F100 > /sys/module/kgdbts/parameters/kgdbts
Or as another example:
echo kgdbts=V2 > /sys/module/kgdbts/parameters/kgdbts
When developing a new kgdb arch specific implementation or
using these tests for the purpose of regression testing,
several invocations are required.
1) Boot with the test suite enabled by using the kernel arguments
"kgdbts=V1F100 kgdbwait"
## If kgdb arch specific implementation has NMI use
"kgdbts=V1N6F100
2) After the system boot run the basic test.
echo kgdbts=V1 > /sys/module/kgdbts/parameters/kgdbts
3) Run the concurrency tests. It is best to use n+1
while loops where n is the number of cpus you have
in your system. The example below uses only two
loops.
## This tests break points on sys_open
while [ 1 ] ; do find / > /dev/null 2>&1 ; done &
while [ 1 ] ; do find / > /dev/null 2>&1 ; done &
echo kgdbts=V1S10000 > /sys/module/kgdbts/parameters/kgdbts
fg # and hit control-c
fg # and hit control-c
## This tests break points on do_fork
while [ 1 ] ; do date > /dev/null ; done &
while [ 1 ] ; do date > /dev/null ; done &
echo kgdbts=V1F1000 > /sys/module/kgdbts/parameters/kgdbts
fg # and hit control-c
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
kgdb core code. Handles the protocol and the arch details.
[ mingo@elte.hu: heavily modified, simplified and cleaned up. ]
[ xemul@openvz.org: use find_task_by_pid_ns ]
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
