Re: [patch 2/2] Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER on x86-64
On Tue, 08 Jan 2008 18:01:48 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > > > The code tries to use the frame pointers to do a backtrace, but if > > it smells iffy or invalid, falls back to the traditional way of > > printing backtraces, to make sure that at least some useful > > backtrace is created. > > That will likely happen in most non trivial cases > (interrupts/exceptions etc.) interrupts at least work just fine... I tested that already -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER on x86-64
Arjan van de Ven <[EMAIL PROTECTED]> writes: > Subject: Use the stack frames to get exact stack-traces for > CONFIG_FRAMEPOINTER on x86-64 > From: Arjan van de Ven <[EMAIL PROTECTED]> > > x86 32 bit already has this feature: This patch uses the stack frames with You would also need to add frame pointers to all .S functions, otherwise it will stop there. > frame pointer into an exact stack trace, by following the frame pointer. > This only affects kernels built with the CONFIG_FRAME_POINTER config option > enabled, and greatly reduces the amount of noise in oopses. Well it's still the wrong way to do this. The correct way is to reintegrate Jan's dwarf2 unwinder. Incidentially that code supports frame pointer unwinding too, but of course with the same limits as described above. > The code tries to use the frame pointers to do a backtrace, but if it smells > iffy or invalid, falls back to the traditional way of printing backtraces, > to make sure that at least some useful backtrace is created. That will likely happen in most non trivial cases (interrupts/exceptions etc.) -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER on x86-64
Arjan van de Ven [EMAIL PROTECTED] writes: Subject: Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER on x86-64 From: Arjan van de Ven [EMAIL PROTECTED] x86 32 bit already has this feature: This patch uses the stack frames with You would also need to add frame pointers to all .S functions, otherwise it will stop there. frame pointer into an exact stack trace, by following the frame pointer. This only affects kernels built with the CONFIG_FRAME_POINTER config option enabled, and greatly reduces the amount of noise in oopses. Well it's still the wrong way to do this. The correct way is to reintegrate Jan's dwarf2 unwinder. Incidentially that code supports frame pointer unwinding too, but of course with the same limits as described above. The code tries to use the frame pointers to do a backtrace, but if it smells iffy or invalid, falls back to the traditional way of printing backtraces, to make sure that at least some useful backtrace is created. That will likely happen in most non trivial cases (interrupts/exceptions etc.) -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER on x86-64
On Tue, 08 Jan 2008 18:01:48 +0100 Andi Kleen [EMAIL PROTECTED] wrote: The code tries to use the frame pointers to do a backtrace, but if it smells iffy or invalid, falls back to the traditional way of printing backtraces, to make sure that at least some useful backtrace is created. That will likely happen in most non trivial cases (interrupts/exceptions etc.) interrupts at least work just fine... I tested that already -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER on x86-64
* Arjan van de Ven <[EMAIL PROTECTED]> wrote: > x86 32 bit already has this feature: This patch uses the stack frames > with frame pointer into an exact stack trace, by following the frame > pointer. This only affects kernels built with the CONFIG_FRAME_POINTER > config option enabled, and greatly reduces the amount of noise in > oopses. nice! Applied. > The code tries to use the frame pointers to do a backtrace, but if it > smells iffy or invalid, falls back to the traditional way of printing > backtraces, to make sure that at least some useful backtrace is > created. > > Due to the fragility and importance of the backtrace code, this needs > to be well reviewed and well tested before merging into mainlne. yeah, agreed. But i think this is still fundamentally more robust than the unwind info based backtracer. Cool stuff! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER on x86-64
Subject: Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER
on x86-64
From: Arjan van de Ven <[EMAIL PROTECTED]>
x86 32 bit already has this feature: This patch uses the stack frames with
frame pointer into an exact stack trace, by following the frame pointer.
This only affects kernels built with the CONFIG_FRAME_POINTER config option
enabled, and greatly reduces the amount of noise in oopses.
The code tries to use the frame pointers to do a backtrace, but if it smells
iffy or invalid, falls back to the traditional way of printing backtraces,
to make sure that at least some useful backtrace is created.
Due to the fragility and importance of the backtrace code, this needs to
be well reviewed and well tested before merging into mainlne.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/x86/kernel/traps_64.c | 72 ++---
1 file changed, 62 insertions(+), 10 deletions(-)
Index: linux-2.6.24-rc7/arch/x86/kernel/traps_64.c
===
--- linux-2.6.24-rc7.orig/arch/x86/kernel/traps_64.c
+++ linux-2.6.24-rc7/arch/x86/kernel/traps_64.c
@@ -221,17 +221,55 @@ static inline int valid_stack_ptr(struct
return p > t && p < t + THREAD_SIZE - size;
}
-static inline unsigned long print_context_stack(struct thread_info *tinfo,
+/* The form of the top of the frame on the stack */
+struct stack_frame {
+ struct stack_frame *next_frame;
+ unsigned long return_address;
+};
+
+
+static inline unsigned long print_context_stack(void *tinfo,
unsigned long *stack, unsigned long ebp,
const struct stacktrace_ops *ops, void *data,
unsigned long *end)
{
+
+#ifdef CONFIG_FRAME_POINTER
+ struct stack_frame *frame = (struct stack_frame *)ebp;
+
/*
-* Print function call entries within a stack. 'cond' is the
-* "end of stackframe" condition, that the 'stack++'
-* iteration will eventually trigger.
+* if EBP is in the current stack frame, use stack frame tracking;
+* otherwise fall back to the traditional method.
*/
- while (valid_stack_ptr(tinfo, stack, 3, end))) {
+
+ if (valid_stack_ptr(tinfo, frame, sizeof(*frame), end)) {
+ while (valid_stack_ptr(tinfo, frame, sizeof(*frame), end)) {
+ struct stack_frame *next;
+ unsigned long addr;
+
+ addr = frame->return_address;
+ if (__kernel_text_address(addr))
+ ops->address(data, addr);
+ /*
+* break out of recursive entries (such as
+* end_of_stack_stop_unwind_function). Also,
+* we can never allow a frame pointer to
+* move downwards!
+*/
+ next = frame->next_frame;
+ ebp = (unsigned long)next;
+ if (next <= frame)
+ break;
+ frame = next;
+ }
+ } else
+#endif
+ /*
+* Print function call entries within a stack.
+* The end condition is either a bound on the stack, or
+* an invalid stack ptr, depending on the caller.
+*/
+ while (valid_stack_ptr(tinfo, stack, 3, end)) {
unsigned long addr = *stack++;
/* Use unlocked access here because except for NMIs
we should be already protected against module unloads */
@@ -258,6 +296,7 @@ void dump_trace(struct task_struct *tsk,
unsigned long *irqstack_end = (unsigned long*)cpu_pda(cpu)->irqstackptr;
unsigned used = 0;
struct thread_info *tinfo;
+ unsigned long ebp = 0;
if (!tsk)
tsk = current;
@@ -270,6 +309,19 @@ void dump_trace(struct task_struct *tsk,
stack = (unsigned long *)tsk->thread.rsp;
}
+#ifdef CONFIG_FRAME_POINTER
+ if (!ebp) {
+ if (tsk == current) {
+ /* Grab ebp right from our regs */
+ asm("movq %%rbp, %0" : "=r" (ebp):);
+ } else {
+ /* ebp is the last reg pushed by switch_to */
+ ebp = *(unsigned long *) tsk->thread.rsp;
+ }
+ }
+#endif
+
+
/*
* Print function call entries in all stacks, starting at the
@@ -286,8 +338,8 @@ void dump_trace(struct task_struct *tsk,
if (ops->stack(data, id) < 0)
break;
- print_context_stack(tinfo, stack, 0, ops,
- data, estack_end);
+ ebp = print_context_stack(tinfo, stack, ebp, ops,
+
[patch 2/2] Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER on x86-64
Subject: Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER
on x86-64
From: Arjan van de Ven [EMAIL PROTECTED]
x86 32 bit already has this feature: This patch uses the stack frames with
frame pointer into an exact stack trace, by following the frame pointer.
This only affects kernels built with the CONFIG_FRAME_POINTER config option
enabled, and greatly reduces the amount of noise in oopses.
The code tries to use the frame pointers to do a backtrace, but if it smells
iffy or invalid, falls back to the traditional way of printing backtraces,
to make sure that at least some useful backtrace is created.
Due to the fragility and importance of the backtrace code, this needs to
be well reviewed and well tested before merging into mainlne.
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
---
arch/x86/kernel/traps_64.c | 72 ++---
1 file changed, 62 insertions(+), 10 deletions(-)
Index: linux-2.6.24-rc7/arch/x86/kernel/traps_64.c
===
--- linux-2.6.24-rc7.orig/arch/x86/kernel/traps_64.c
+++ linux-2.6.24-rc7/arch/x86/kernel/traps_64.c
@@ -221,17 +221,55 @@ static inline int valid_stack_ptr(struct
return p t p t + THREAD_SIZE - size;
}
-static inline unsigned long print_context_stack(struct thread_info *tinfo,
+/* The form of the top of the frame on the stack */
+struct stack_frame {
+ struct stack_frame *next_frame;
+ unsigned long return_address;
+};
+
+
+static inline unsigned long print_context_stack(void *tinfo,
unsigned long *stack, unsigned long ebp,
const struct stacktrace_ops *ops, void *data,
unsigned long *end)
{
+
+#ifdef CONFIG_FRAME_POINTER
+ struct stack_frame *frame = (struct stack_frame *)ebp;
+
/*
-* Print function call entries within a stack. 'cond' is the
-* end of stackframe condition, that the 'stack++'
-* iteration will eventually trigger.
+* if EBP is in the current stack frame, use stack frame tracking;
+* otherwise fall back to the traditional method.
*/
- while (valid_stack_ptr(tinfo, stack, 3, end))) {
+
+ if (valid_stack_ptr(tinfo, frame, sizeof(*frame), end)) {
+ while (valid_stack_ptr(tinfo, frame, sizeof(*frame), end)) {
+ struct stack_frame *next;
+ unsigned long addr;
+
+ addr = frame-return_address;
+ if (__kernel_text_address(addr))
+ ops-address(data, addr);
+ /*
+* break out of recursive entries (such as
+* end_of_stack_stop_unwind_function). Also,
+* we can never allow a frame pointer to
+* move downwards!
+*/
+ next = frame-next_frame;
+ ebp = (unsigned long)next;
+ if (next = frame)
+ break;
+ frame = next;
+ }
+ } else
+#endif
+ /*
+* Print function call entries within a stack.
+* The end condition is either a bound on the stack, or
+* an invalid stack ptr, depending on the caller.
+*/
+ while (valid_stack_ptr(tinfo, stack, 3, end)) {
unsigned long addr = *stack++;
/* Use unlocked access here because except for NMIs
we should be already protected against module unloads */
@@ -258,6 +296,7 @@ void dump_trace(struct task_struct *tsk,
unsigned long *irqstack_end = (unsigned long*)cpu_pda(cpu)-irqstackptr;
unsigned used = 0;
struct thread_info *tinfo;
+ unsigned long ebp = 0;
if (!tsk)
tsk = current;
@@ -270,6 +309,19 @@ void dump_trace(struct task_struct *tsk,
stack = (unsigned long *)tsk-thread.rsp;
}
+#ifdef CONFIG_FRAME_POINTER
+ if (!ebp) {
+ if (tsk == current) {
+ /* Grab ebp right from our regs */
+ asm(movq %%rbp, %0 : =r (ebp):);
+ } else {
+ /* ebp is the last reg pushed by switch_to */
+ ebp = *(unsigned long *) tsk-thread.rsp;
+ }
+ }
+#endif
+
+
/*
* Print function call entries in all stacks, starting at the
@@ -286,8 +338,8 @@ void dump_trace(struct task_struct *tsk,
if (ops-stack(data, id) 0)
break;
- print_context_stack(tinfo, stack, 0, ops,
- data, estack_end);
+ ebp = print_context_stack(tinfo, stack, ebp, ops,
+
Re: [patch 2/2] Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER on x86-64
* Arjan van de Ven [EMAIL PROTECTED] wrote: x86 32 bit already has this feature: This patch uses the stack frames with frame pointer into an exact stack trace, by following the frame pointer. This only affects kernels built with the CONFIG_FRAME_POINTER config option enabled, and greatly reduces the amount of noise in oopses. nice! Applied. The code tries to use the frame pointers to do a backtrace, but if it smells iffy or invalid, falls back to the traditional way of printing backtraces, to make sure that at least some useful backtrace is created. Due to the fragility and importance of the backtrace code, this needs to be well reviewed and well tested before merging into mainlne. yeah, agreed. But i think this is still fundamentally more robust than the unwind info based backtracer. Cool stuff! Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
