summaryrefslogtreecommitdiff
path: root/drivers/misc/kgdbts.c
AgeCommit message (Collapse)AuthorFilesLines
2013-03-02kgdb/kgdbts: support ppc64Tiejun Chen1-0/+2
We can't look up the address of the entry point of the function simply via that function symbol for all architectures. For PPC64 ABI, actually there is a function descriptors structure. A function descriptor is a three doubleword data structure that contains the following values: * The first doubleword contains the address of the entry point of the function. * The second doubleword contains the TOC base address for the function. * The third doubleword contains the environment pointer for languages such as Pascal and PL/1. So we should call a wapperred dereference_function_descriptor() to get the address of the entry point of the function. Note this is also safe for other architecture after refer to "include/asm-generic/sections.h" since: dereference_function_descriptor(p) always is (p) if without arched definition. Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-03-30x86,kgdb: Fix DEBUG_RODATA limitation using text_poke()Jason Wessel1-17/+0
There has long been a limitation using software breakpoints with a kernel compiled with CONFIG_DEBUG_RODATA going back to 2.6.26. For this particular patch, it will apply cleanly and has been tested all the way back to 2.6.36. The kprobes code uses the text_poke() function which accommodates writing a breakpoint into a read-only page. The x86 kgdb code can solve the problem similarly by overriding the default breakpoint set/remove routines and using text_poke() directly. The x86 kgdb code will first attempt to use the traditional probe_kernel_write(), and next try using a the text_poke() function. The break point install method is tracked such that the correct break point removal routine will get called later on. Cc: x86@kernel.org Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: stable@vger.kernel.org # >= 2.6.36 Inspried-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-03-30kgdbts: (2 of 2) fix single step awareness to work correctly with SMPJason Wessel1-11/+62
The do_fork and sys_open tests have never worked properly on anything other than a UP configuration with the kgdb test suite. This is because the test suite did not fully implement the behavior of a real debugger. A real debugger tracks the state of what thread it asked to single step and can correctly continue other threads of execution or conditionally stop while waiting for the original thread single step request to return. Below is a simple method to cause a fatal kernel oops with the kgdb test suite on a 2 processor ARM system: while [ 1 ] ; do ls > /dev/null 2> /dev/null; done& while [ 1 ] ; do ls > /dev/null 2> /dev/null; done& echo V1I1F100 > /sys/module/kgdbts/parameters/kgdbts Very soon after starting the test the kernel will start warning with messages like: kgdbts: BP mismatch c002487c expected c0024878 ------------[ cut here ]------------ WARNING: at drivers/misc/kgdbts.c:317 check_and_rewind_pc+0x9c/0xc4() [<c01f6520>] (check_and_rewind_pc+0x9c/0xc4) [<c01f595c>] (validate_simple_test+0x3c/0xc4) [<c01f60d4>] (run_simple_test+0x1e8/0x274) The kernel will eventually recovers, but the test suite has completely failed to test anything useful. This patch implements behavior similar to a real debugger that does not rely on hardware single stepping by using only software planted breakpoints. In order to mimic a real debugger, the kgdb test suite now tracks the most recent thread that was continued (cont_thread_id), with the intent to single step just this thread. When the response to the single step request stops in a different thread that hit the original break point that thread will now get continued, while the debugger waits for the thread with the single step pending. Here is a high level description of the sequence of events. cont_instead_of_sstep = 0; 1) set breakpoint at do_fork 2) continue 3) Save the thread id where we stop to cont_thread_id 4) Remove breakpoint at do_fork 5) Reset the PC if needed depending on kernel exception type 6) soft single step 7) Check where we stopped if current thread != cont_thread_id { if (here for more than 2 times for the same thead) { ### must be a really busy system, start test again ### goto step 1 } goto step 5 } else { cont_instead_of_sstep = 0; } 8) clean up and run test again if needed 9) Clear out any threads that were waiting on a break point at the point in time the test is ended with get_cont_catch(). This happens sometimes because breakpoints are used in place of single stepping and some threads could have been in the debugger exception handling queue because breakpoints were hit concurrently on different CPUs. This also means we wait at least one second before unplumbing the debugger connection at the very end, so as respond to any debug threads waiting to be serviced. Cc: stable@vger.kernel.org # >= 3.0 Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-03-30kgdbts: (1 of 2) fix single step awareness to work correctly with SMPJason Wessel1-11/+43
The do_fork and sys_open tests have never worked properly on anything other than a UP configuration with the kgdb test suite. This is because the test suite did not fully implement the behavior of a real debugger. A real debugger tracks the state of what thread it asked to single step and can correctly continue other threads of execution or conditionally stop while waiting for the original thread single step request to return. Below is a simple method to cause a fatal kernel oops with the kgdb test suite on a 4 processor x86 system: while [ 1 ] ; do ls > /dev/null 2> /dev/null; done& while [ 1 ] ; do ls > /dev/null 2> /dev/null; done& while [ 1 ] ; do ls > /dev/null 2> /dev/null; done& while [ 1 ] ; do ls > /dev/null 2> /dev/null; done& echo V1I1F1000 > /sys/module/kgdbts/parameters/kgdbts Very soon after starting the test the kernel will oops with a message like: kgdbts: BP mismatch 3b7da66480 expected ffffffff8106a590 WARNING: at drivers/misc/kgdbts.c:303 check_and_rewind_pc+0xe0/0x100() Call Trace: [<ffffffff812994a0>] check_and_rewind_pc+0xe0/0x100 [<ffffffff81298945>] validate_simple_test+0x25/0xc0 [<ffffffff81298f77>] run_simple_test+0x107/0x2c0 [<ffffffff81298a18>] kgdbts_put_char+0x18/0x20 The warn will turn to a hard kernel crash shortly after that because the pc will not get properly rewound to the right value after hitting a breakpoint leading to a hard lockup. This change is broken up into 2 pieces because archs that have hw single stepping (2.6.26 and up) need different changes than archs that do not have hw single stepping (3.0 and up). This change implements the correct behavior for an arch that supports hw single stepping. A minor defect was fixed where sys_open should be do_sys_open for the sys_open break point test. This solves the problem of running a 64 bit with a 32 bit user space. The sys_open() never gets called when using the 32 bit file system for the kgdb testsuite because the 32 bit binaries invoke the compat_sys_open() call leading to the test never completing. In order to mimic a real debugger, the kgdb test suite now tracks the most recent thread that was continued (cont_thread_id), with the intent to single step just this thread. When the response to the single step request stops in a different thread that hit the original break point that thread will now get continued, while the debugger waits for the thread with the single step pending. Here is a high level description of the sequence of events. cont_instead_of_sstep = 0; 1) set breakpoint at do_fork 2) continue 3) Save the thread id where we stop to cont_thread_id 4) Remove breakpoint at do_fork 5) Reset the PC if needed depending on kernel exception type 6) if (cont_instead_of_sstep) { continue } else { single step } 7) Check where we stopped if current thread != cont_thread_id { cont_instead_of_sstep = 1; goto step 5 } else { cont_instead_of_sstep = 0; } 8) clean up and run test again if needed Cc: stable@vger.kernel.org # >= 2.6.26 Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2012-03-30kgdbts: Fix kernel oops with CONFIG_DEBUG_RODATAJason Wessel1-24/+28
On x86 the kgdb test suite will oops when the kernel is compiled with CONFIG_DEBUG_RODATA and you run the tests after boot time. This is regression has existed since 2.6.26 by commit: b33cb815 (kgdbts: Use HW breakpoints with CONFIG_DEBUG_RODATA). The test suite can use hw breakpoints for all the tests, but it has to execute the hardware breakpoint specific tests first in order to determine that the hw breakpoints actually work. Specifically the very first test causes an oops: # echo V1I1 > /sys/module/kgdbts/parameters/kgdbts kgdb: Registered I/O driver kgdbts. kgdbts:RUN plant and detach test Entering kdb (current=0xffff880017aa9320, pid 1078) on processor 0 due to Keyboard Entry [0]kdb> kgdbts: ERROR PUT: end of test buffer on 'plant_and_detach_test' line 1 expected OK got $E14#aa WARNING: at drivers/misc/kgdbts.c:730 run_simple_test+0x151/0x2c0() [...oops clipped...] This commit re-orders the running of the tests and puts the RODATA check into its own function so as to correctly avoid the kernel oops by detecting and using the hw breakpoints. Cc: <stable@vger.kernel.org> # >= 2.6.26 Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2011-11-01drivers/misc: Add module.h to files who are really modular.Paul Gortmaker1-0/+1
These files really need the full module.h header file present, but were just getting it implicitly before. Fix it up in advance so we avoid build failures once the cleanup commit is present. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-01kgdbts: only use new asm-generic/ptrace.h api when neededMike Frysinger1-1/+4
The new instruction_pointer_set helper is defined for people who have converted to asm-generic/ptrace.h, so don't use it generally unless the arch needs it (in which case it has been converted). This should fix building of kgdb tests for arches not yet converted. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Acked-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-27kgdbts: unify/generalize gdb breakpoint adjustmentMike Frysinger1-18/+11
The Blackfin arch, like the x86 arch, needs to adjust the PC manually after a breakpoint is hit as normally this is handled by the remote gdb. However, rather than starting another arch ifdef mess, create a common GDB_ADJUSTS_BREAK_OFFSET define for any arch to opt-in via their kgdb.h. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Paul Mundt <lethal@linux-sh.org> Acked-by: Dongdong Deng <dongdong.deng@windriver.com> Cc: Sergei Shtylyov <sshtylyov@mvista.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-31Fix common misspellingsLucas De Marchi1-1/+1
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-26kgdboc,kgdbts: strlen() doesn't count the terminatorDan Carpenter1-1/+1
This is an off by one because strlen() doesn't count the null terminator. We strcpy() these strings into an array of size MAX_CONFIG_LEN. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2010-10-29kgdbts: prevent re-entry to kgdbts before it unregistersDongdong Deng1-14/+2
The "kgdb_connected" variable of debug_core just indicates whether or not kgdbts is connected to the debug_core. It does not completely prevent a script from trying invoke kgdbts again and possibly crashing the system (see Call Trace below). The configured variable in kgtbts can be used instead of kgdb_connected instead of kgdb_connected. The cleanup_kgdbts() can also be removed because there is no possible way to build kgdbts as a kernel module that you could unload with rmmod. Call Trace: ----------------------------------------------------------------- root:/$ echo kgdbts=V1S1000 > /sys/module/kgdbts/parameters/kgdbts kgdb: Unregistered I/O driver kgdbts, debugger disabled. ------------[ cut here ]------------ WARNING: at kernel/debug/debug_core.c:1002 kgdb_unregister_io_module+0xec/0x100() Hardware name: Moon Creek platform Modules linked in: Pid: 664, comm: sh Not tainted 2.6.34.1-WR4.0.0.0_standard #58 Call Trace: [<c103b1ed>] warn_slowpath_common+0x6d/0xa0 [<c1079fdc>] ? kgdb_unregister_io_module+0xec/0x100 [<c1079fdc>] ? kgdb_unregister_io_module+0xec/0x100 [<c10544e0>] ? param_attr_store+0x0/0x20 [<c103b235>] warn_slowpath_null+0x15/0x20 [<c1079fdc>] kgdb_unregister_io_module+0xec/0x100 [<c124e4ea>] cleanup_kgdbts+0x1a/0x20 [<c124eced>] param_set_kgdbts_var+0x6d/0xb0 [<c124ec80>] ? param_set_kgdbts_var+0x0/0xb0 [<c10544f7>] param_attr_store+0x17/0x20 [<c105457c>] module_attr_store+0x2c/0x40 [<c111fe84>] sysfs_write_file+0x94/0xf0 [<c10d42f6>] vfs_write+0x96/0x130 [<c111fdf0>] ? sysfs_write_file+0x0/0xf0 [<c10d44d6>] sys_write+0x46/0xd0 [<c13bf329>] system_call_done+0x0/0x4 ---[ end trace 4eb028c6ee43154c ]--- kgdb: Unregistered I/O driver kgdbts, debugger disabled. ----------------------------------------------------------------- [jason.wessel@windriver.com: remove cleanup_kgdbts() ] Signed-off-by: Dongdong Deng <dongdong.deng@windriver.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2010-04-02kgdbts,sh: Add in breakpoint pc offset for superhJason Wessel1-0/+6
The kgdb test suite mimics the behavior of gdb. For the sh architecture the pc must be decremented by 2 for software breakpoint. Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Acked-by: Paul Mundt <lethal@linux-sh.org>
2009-12-11kgdb: Replace strstr() by strchr() for single-character needlesGeert Uytterhoeven1-4/+4
Some versions of gcc replace calls to strstr() with single-character "needle" string parameters by calls to strchr() behind our back. This causes linking errors if strchr() is defined as an inline function in <asm/string.h> (e.g. on m68k, which BTW doesn't have kgdb support). Prevent this by explicitly calling strchr() instead. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2009-12-11kgdbts: Read buffer overflowRoel Kluin1-0/+6
Prevent write to put_buf[BUFMAX] in kgdb test suite. If put_buf_cnt was BUFMAX - 1 at the earlier test, `\0' is written to put_buf[BUFMAX]. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2008-05-28kgdbts: Use HW breakpoints with CONFIG_DEBUG_RODATAJason Wessel1-4/+24
Whenever CONFIG_DEBUG_RODATA is set in the kernel config many kernel text sections become read-only, and the use of software breakpoints in the kgdb tests will cause the kernel to fail to complete the start up. Until such time that there is an official API for modifying read-only text sections hardware breakpoints must be used to run the do_fork or sys_open tests or the tests get skipped. Also fix the duplicated include reported by: Huang Weiyi <weiyi.huang@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2008-05-28kgdb: use common ascii helpers and put_unaligned_be32 helperHarvey Harrison1-3/+2
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2008-05-05kgdb: 1000 loops for the single step test in kgdbtsJason Wessel1-2/+13
The single step test is not terribly costly and it should be able to pass at 1000 loops successfully in under 1 second. A non-kgdb timing regression was found using this test, but it did not occur frequently because by default the test was only executed a single time. This patch changes the default for the single step test to 1000 iterations and allows for individual configuration of the single step test to further exercise the kgdb subsystem when needed. Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2008-05-05kgdb: trivial sparse fixes in kgdb test-suiteHarvey Harrison1-30/+30
Shadowed variable and integer as NULL pointer fixes: drivers/misc/kgdbts.c:877:6: warning: symbol 'sys_open_test' shadows an earlier one drivers/misc/kgdbts.c:537:27: originally declared here drivers/misc/kgdbts.c:378:22: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:386:22: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:468:30: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:472:15: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:502:30: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:506:30: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:509:30: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:523:20: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:527:20: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:530:15: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:541:21: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:545:21: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:548:15: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:559:30: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:563:15: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:573:16: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:574:19: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:578:15: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:588:16: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:589:19: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:593:15: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:602:16: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:604:15: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:925:3: warning: Using plain integer as NULL pointer drivers/misc/kgdbts.c:938:3: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2008-04-29kgdbts: Sparc needs sstep emulation.David S. Miller1-1/+1
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-04-17kgdb: allow static kgdbts boot configurationJason Wessel1-17/+24
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>
2008-04-17kgdb: add kgdb internal test suiteJason Wessel1-0/+1083
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>