v1:
* Copy thread info only when we are from !user mode since we'll get kernel stack
coming from usr directly.
* remove save/restore EX_R14/EX_R15 since DBG_EXCEPTION_PROLOG already covered
this.
* use CURRENT_THREAD_INFO() conveniently to get thread.
* fix some typos
* add a patch to make sure gdb can generate a single step properly to invoke a
kgdb state.
* add a patch to if we need to replay an interrupt, we shouldn't restore that
previous backup thread info to make sure we can replay an interrupt lately
with a proper thread info.
* rebase latest powerpc git tree
v0:
This patchset is used to support kgdb for book3e.
Tiejun Chen (6):
powerpc/book3e: load critical/machine/debug exception stack
powerpc/book3e: store critical/machine/debug exception thread info
book3e/kgdb: update thread's dbcr0
book3e/kgdb: Fix a single stgep case of lazy IRQ
powerpc/book3e: support kgdb for kernel space
kgdb/kgdbts: support ppc64
arch/powerpc/kernel/exceptions-64e.S | 60 +++++++++++++++++++++++++++++++---
arch/powerpc/kernel/irq.c | 10 ++++++
arch/powerpc/kernel/kgdb.c | 13 +++++++-
drivers/misc/kgdbts.c | 2 ++
4 files changed, 80 insertions(+), 5 deletions(-)
Tiejun
We always alloc critical/machine/debug check exceptions. This is
different from the normal exception. So we should load these exception
stack properly like we did for booke.
Signed-off-by: Tiejun Chen <redacted>
---
arch/powerpc/kernel/exceptions-64e.S | 40 +++++++++++++++++++++++++++++++---
1 file changed, 37 insertions(+), 3 deletions(-)
We need to store thread info to these exception thread info like something
we already did for PPC32.
Signed-off-by: Tiejun Chen <redacted>
---
arch/powerpc/kernel/exceptions-64e.S | 15 +++++++++++++++
1 file changed, 15 insertions(+)
gdb always need to generate a single step properly to invoke
a kgdb state. But with lazy interrupt, book3e can't always
trigger a debug exception with a single step since the current
is blocked for handling those pending exception, then we miss
that expected dbcr configuration at last to generate a debug
exception.
So here we also update thread's dbcr0 to make sure the current
can go back with that missed dbcr0 configuration.
Signed-off-by: Tiejun Chen <redacted>
---
arch/powerpc/kernel/kgdb.c | 10 ++++++++++
1 file changed, 10 insertions(+)
@@ -426,8 +426,18 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code,/* set the trace bit if we're stepping */if(remcom_in_buffer[0]=='s'){#ifdef CONFIG_PPC_ADV_DEBUG_REGS+#ifdef CONFIG_PPC_BOOK3E+/* With lazy interrut we have to update thread dbcr0 here+*tomakesurewecansetdebugproperlyatlasttoinvoke+*kgdbagaintoworkwell.+*/+current->thread.dbcr0=+mfspr(SPRN_DBCR0)|DBCR0_IC|DBCR0_IDM;+mtspr(SPRN_DBCR0,current->thread.dbcr0);+#elsemtspr(SPRN_DBCR0,mfspr(SPRN_DBCR0)|DBCR0_IC|DBCR0_IDM);+#endiflinux_regs->msr|=MSR_DE;#elselinux_regs->msr|=MSR_SE;
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 <redacted>
---
drivers/misc/kgdbts.c | 2 ++
1 file changed, 2 insertions(+)
Currently we need to skip this for supporting KGDB.
Signed-off-by: Tiejun Chen <redacted>
---
arch/powerpc/kernel/exceptions-64e.S | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
When we're in kgdb_singlestep(), we have to work around to get
thread_info by copying from the kernel stack before calling
kgdb_handle_exception(), then copying it back afterwards.
But for PPC64, we have a lazy interrupt implementation. So after
copying thread info frome kernle stack, if we need to replay an
interrupt, we shouldn't restore that previous backup thread info
to make sure we can replay an interrupt lately with a proper
thread info.
This patch use __check_irq_replay() to guarantee this process.
Signed-off-by: Tiejun Chen <redacted>
---
arch/powerpc/kernel/irq.c | 10 ++++++++++
arch/powerpc/kernel/kgdb.c | 3 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
From: Kumar Gala <hidden> Date: 2012-12-20 18:42:09
On Dec 20, 2012, at 3:08 AM, Tiejun Chen wrote:
quoted hunk
gdb always need to generate a single step properly to invoke
a kgdb state. But with lazy interrupt, book3e can't always
trigger a debug exception with a single step since the current
is blocked for handling those pending exception, then we miss
that expected dbcr configuration at last to generate a debug
exception.
=20
So here we also update thread's dbcr0 to make sure the current
can go back with that missed dbcr0 configuration.
=20
Signed-off-by: Tiejun Chen <redacted>
---
arch/powerpc/kernel/kgdb.c | 10 ++++++++++
1 file changed, 10 insertions(+)
=20
gdb always need to generate a single step properly to invoke
a kgdb state. But with lazy interrupt, book3e can't always
trigger a debug exception with a single step since the current
is blocked for handling those pending exception, then we miss
that expected dbcr configuration at last to generate a debug
exception.
So here we also update thread's dbcr0 to make sure the current
can go back with that missed dbcr0 configuration.
Signed-off-by: Tiejun Chen <redacted>
---
arch/powerpc/kernel/kgdb.c | 10 ++++++++++
1 file changed, 10 insertions(+)
@@ -426,8 +426,18 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code,
/* set the trace bit if we're stepping */
if (remcom_in_buffer[0] == 's') {
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
+#ifdef CONFIG_PPC_BOOK3E
Should this really be CONFIG_PPC64 or CONFIG_PPC_BOOK3E_64?
Yes, I think CONFIG_PPC_BOOK3E_64 is better currently. Because I didn't validate
this on power arch since I have no a real machine :)
quoted
+ /* With lazy interrut we have to update thread dbcr0 here
+ * to make sure we can set debug properly at last to invoke
+ * kgdb again to work well.
+ */
+ current->thread.dbcr0 =
+ mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM;
+ mtspr(SPRN_DBCR0, current->thread.dbcr0);
+#else
mtspr(SPRN_DBCR0,
mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM);
+#endif
@@ -426,8 +426,15 @@ int kgdb_arch_handle_exception(int vector, int signo, int
err_code,
/* set the trace bit if we're stepping */
if (remcom_in_buffer[0] == 's') {
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
- mtspr(SPRN_DBCR0,
- mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM);
+ dbcr0 = mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM;
+ mtspr(SPRN_DBCR0, dbcr0);
+#ifdef CONFIG_PPC_BOOK3E_64
+ /* With lazy interrut we have to update thread dbcr0 here
+ * to make sure we can set debug properly at last to invoke
+ * kgdb again to work well.
+ */
+ current->thread.dbcr0 = dbcr0;
+#endif
linux_regs->msr |= MSR_DE;
#else
linux_regs->msr |= MSR_SE;
--
1.7.9.5
Tiejun