Commit Graph

13 Commits

Author SHA1 Message Date
Doug Anderson 001bf455d2 ARM: 8428/1: kgdb: Fix registers on sleeping tasks
Dumping registers from other sleeping tasks in KGDB was totally
failing for me.  All registers were reported as 0 in many cases.

The code was using task_pt_regs(task) to try to get other thread
registers.  This doesn't appear to be the right place to look.  From
my tests, I saw non-zero values in this structure when we were looking
at a kernel thread that had a userspace task associated with it, but
it contained the register values from the userspace task.  So even in
the cases where registers weren't reported as 0 we were still not
showing the right thing.

Instead of using task_pt_regs(task) let's use task_thread_info(task).
This is the same place that is referred to when doing a dump of all
sleeping task stacks (kdb_show_stack() -> show_stack() ->
dump_backtrace() -> unwind_backtrace() -> thread_saved_sp()).

As further evidence that this is the right thing to do, you can find
the following comment in "gdbstub.c" right before it calls
sleeping_thread_to_gdb_regs():
  Pull stuff saved during switch_to; nothing else is accessible (or
  even particularly relevant).  This should be enough for a stack
  trace.
...and if you look at switch_to() it only saves r4-r11, sp and lr.
Those are the same registers that I'm getting out of the
task_thread_info().

With this change you can use "info thread" to see all tasks in the
kernel and you can switch to other tasks and examine them in gdb.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Stephen Boyd <sboyd@codeurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-10-03 16:36:45 +01:00
Doug Anderson 7ae85dc768 ARM: 8425/1: kgdb: Don't try to stop the machine when setting breakpoints
In (23a4e40 arm: kgdb: Handle read-only text / modules) we moved to
using patch_text() to set breakpoints so that we could handle the case
when we had CONFIG_DEBUG_RODATA.  That patch used patch_text().
Unfortunately, patch_text() assumes that we're not in atomic context
when it runs since it needs to grab a mutex and also wait for other
CPUs to stop (which it does with a completion).

This would result in a stack crawl if you had
CONFIG_DEBUG_ATOMIC_SLEEP and tried to set a breakpoint in kgdb.  The
crawl looked something like:

 BUG: scheduling while atomic: swapper/0/0/0x00010007
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-00133-geb63b34 #1073
 Hardware name: Rockchip (Device Tree)
  (unwind_backtrace) from [<c00133d4>] (show_stack+0x20/0x24)
  (show_stack) from [<c05400e8>] (dump_stack+0x84/0xb8)
  (dump_stack) from [<c004913c>] (__schedule_bug+0x54/0x6c)
  (__schedule_bug) from [<c054065c>] (__schedule+0x80/0x668)
  (__schedule) from [<c0540cfc>] (schedule+0xb8/0xd4)
  (schedule) from [<c0543a3c>] (schedule_timeout+0x2c/0x234)
  (schedule_timeout) from [<c05417c0>] (wait_for_common+0xf4/0x188)
  (wait_for_common) from [<c0541874>] (wait_for_completion+0x20/0x24)
  (wait_for_completion) from [<c00a0104>] (__stop_cpus+0x58/0x70)
  (__stop_cpus) from [<c00a0580>] (stop_cpus+0x3c/0x54)
  (stop_cpus) from [<c00a06c4>] (__stop_machine+0xcc/0xe8)
  (__stop_machine) from [<c00a0714>] (stop_machine+0x34/0x44)
  (stop_machine) from [<c00173e8>] (patch_text+0x28/0x34)
  (patch_text) from [<c001733c>] (kgdb_arch_set_breakpoint+0x40/0x4c)
  (kgdb_arch_set_breakpoint) from [<c00a0d68>] (kgdb_validate_break_address+0x2c/0x60)
  (kgdb_validate_break_address) from [<c00a0e90>] (dbg_set_sw_break+0x1c/0xdc)
  (dbg_set_sw_break) from [<c00a2e88>] (gdb_serial_stub+0x9c4/0xba4)
  (gdb_serial_stub) from [<c00a11cc>] (kgdb_cpu_enter+0x1f8/0x60c)
  (kgdb_cpu_enter) from [<c00a18cc>] (kgdb_handle_exception+0x19c/0x1d0)
  (kgdb_handle_exception) from [<c0016f7c>] (kgdb_compiled_brk_fn+0x30/0x3c)
  (kgdb_compiled_brk_fn) from [<c00091a4>] (do_undefinstr+0x1a4/0x20c)
  (do_undefinstr) from [<c001400c>] (__und_svc_finish+0x0/0x34)

It turns out that when we're in kgdb all the CPUs are stopped anyway
so there's no reason we should be calling patch_text().  We can
instead directly call __patch_text() which assumes that CPUs have
already been stopped.

Fixes: 23a4e4050b ("arm: kgdb: Handle read-only text / modules")
Reported-by: Aapo Vienamo <avienamo@nvidia.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-09-16 23:58:46 +01:00
Wang Nan fca08f326a ARM: probes: move all probe code to dedicate directory
In discussion on LKML (https://lkml.org/lkml/2014/11/28/158), Russell
King suggests to move all probe related code to arch/arm/probes. This
patch does the work. Due to dependency on 'arch/arm/kernel/patch.h', this
patch also moves patch.h to 'arch/arm/include/asm/patch.h', and related
'#include' directives are also midified to '#include <asm/patch.h>'.

Following is an overview of this patch:

 ./arch/arm/kernel/               ./arch/arm/probes/
 |-- Makefile                     |-- Makefile
 |-- probes-arm.c          ==>    |-- decode-arm.c
 |-- probes-arm.h          ==>    |-- decode-arm.h
 |-- probes-thumb.c        ==>    |-- decode-thumb.c
 |-- probes-thumb.h        ==>    |-- decode-thumb.h
 |-- probes.c              ==>    |-- decode.c
 |-- probes.h              ==>    |-- decode.h
 |                                |-- kprobes
 |                                |   |-- Makefile
 |-- kprobes-arm.c         ==>    |   |-- actions-arm.c
 |-- kprobes-common.c      ==>    |   |-- actions-common.c
 |-- kprobes-thumb.c       ==>    |   |-- actions-thumb.c
 |-- kprobes.c             ==>    |   |-- core.c
 |-- kprobes.h             ==>    |   |-- core.h
 |-- kprobes-test-arm.c    ==>    |   |-- test-arm.c
 |-- kprobes-test.c        ==>    |   |-- test-core.c
 |-- kprobes-test.h        ==>    |   |-- test-core.h
 |-- kprobes-test-thumb.c  ==>    |   `-- test-thumb.c
 |                                `-- uprobes
 |                                    |-- Makefile
 |-- uprobes-arm.c         ==>        |-- actions-arm.c
 |-- uprobes.c             ==>        |-- core.c
 |-- uprobes.h             ==>        `-- core.h
 |
 `-- patch.h               ==>    arch/arm/include/asm/patch.h

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
2015-01-09 09:36:50 +00:00
Doug Anderson 23a4e4050b arm: kgdb: Handle read-only text / modules
Handle the case where someone has set the text segment of the kernel
as read-only by using the newly introduced "patch" mechanism.

Signed-off-by: Doug Anderson <dianders@chromium.org>
[kees: switched structure size check to BUILD_BUG_ON (sboyd)]
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
2014-10-16 14:38:53 -07:00
Omar Sandoval 6bf755db4d ARM: 8124/1: don't enter kgdb when userspace executes a kgdb break instruction
The kgdb breakpoint hooks (kgdb_brk_fn and kgdb_compiled_brk_fn)
should only be entered when a kgdb break instruction is executed
from the kernel. Otherwise, if kgdb is enabled, a userspace program
can cause the kernel to drop into the debugger by executing either
KGDB_BREAKINST or KGDB_COMPILED_BREAK.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Omar Sandoval <osandov@osandov.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-08-02 15:20:30 +01:00
Rabin Vincent 834b2964b7 kgdb,arm: fix register dump
DBG_MAX_REG_NUM incorrectly had the number of indices in the GDB regs
array rather than the number of registers, leading to an oops when the
"rd" command is used in KDB.

Cc: stable@kernel.org
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2010-10-29 13:14:40 -05:00
eric miao 2f174847b0 ARM: 6326/1: kgdb: fix GDB_MAX_REGS no longer used
According to commit 22eeef4bb2

    kgdb,arm: Individual register get/set for arm

It's now replaced by DBG_MAX_REG_NUM.

Cc: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-08-14 09:28:35 +01:00
Jason Wessel 62a0309c4c arm,kgdb: Add ability to trap into debugger on notify_die
Now that ARM implements the notify die handlers, add the ability for
the kernel debugger to receive the notifications.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: Russell King <linux@arm.linux.org.uk>
CC: linux-arm-kernel@lists.infradead.org
2010-08-05 09:22:22 -05:00
Jason Wessel 22eeef4bb2 kgdb,arm: Individual register get/set for arm
Implement the ability to individually get and set registers for kdb
and kgdb for arm.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: Russell King <linux@arm.linux.org.uk>
CC: linux-arm-kernel@lists.infradead.org
2010-08-05 09:22:21 -05:00
Jason Wessel dcc7871128 kgdb: core changes to support kdb
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 <mingo@elte.hu>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Acked-by: Martin Hicks <mort@sgi.com>
2010-05-20 21:04:21 -05:00
Will Deacon 5d8614cc5d ARM: 5989/1: ARM: KGDB: add support for SMP platforms
To support SMP platforms, KGDB requires the architecture backend to
implement the kgdb_roundup_cpus function.

This patch, taken against 2.6.33, implements the function for ARM based
on the MIPS port.

Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Jean-Michel Hautbois <jhautbois@gmail.com>
Cc: KGDB Mailing List <kgdb-bugreport@lists.sourceforge.net>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-03-15 14:33:04 +00:00
Jason Wessel d7161a6534 kgdb, x86, arm, mips, powerpc: ignore user space single stepping
On the x86 arch, user space single step exceptions should be ignored
if they occur in the kernel space, such as ptrace stepping through a
system call.

First check if it is kgdb that is executing a single step, then ensure
it is not an accidental traversal into the user space, while in kgdb,
any other time the TIF_SINGLESTEP is set, kgdb should ignore the
exception.

On x86, arm, mips and powerpc, the kgdb_contthread usage was
inconsistent with the way single stepping is implemented in the kgdb
core.  The arch specific stub should always set the
kgdb_cpu_doing_single_step correctly if it is single stepping.  This
allows kgdb to correctly process an instruction steps if ptrace
happens to be requesting an instruction step over a system call.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
2008-09-26 10:36:41 -05:00
Jason Wessel 5cbad0ebf4 kgdb: support for ARCH=arm
This patch adds the ARCH=arm specific a kgdb backend, originally
written by Deepak Saxena <dsaxena@plexity.net> and George Davis
<gdavis@mvista.com>.  Geoff Levand <geoffrey.levand@am.sony.com>,
Nicolas Pitre, Manish Lachwani, and Jason Wessel have contributed
various fixups here as well.

The KGDB patch makes one change to the core ARM architecture such that
the traps are initialized early for use with the debugger or other
subsystems.

[ mingo@elte.hu: small cleanups. ]
[ ben-linux@fluff.org: fixed early_trap_init ]

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Acked-by: Deepak Saxena <dsaxena@plexity.net>
2008-07-23 11:30:15 -05:00