* [PATCH] m68knommu: add pretty back strace
@ 2008-05-01 2:16 Greg Ungerer
2008-05-02 19:27 ` Paulo Marques
0 siblings, 1 reply; 5+ messages in thread
From: Greg Ungerer @ 2008-05-01 2:16 UTC (permalink / raw)
To: torvalds; +Cc: akpm, gerg, linux-kernel
From: Sebastian Siewior <bigeasy@linutronix.de>
With this patch and
CONFIG_FRAME_POINTER=y
CONFIG_KALLSYMS=y
The backtrace shows resolved function names and their numeric
address.
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.25/arch/m68knommu/kernel/traps.c linux-2.6.25-uc0/arch/m68knommu/kernel/traps.c
--- linux-2.6.25/arch/m68knommu/kernel/traps.c 2008-04-17 12:49:44.000000000 +1000
+++ linux-2.6.25-uc0/arch/m68knommu/kernel/traps.c 2008-04-28 17:05:44.000000000 +1000
@@ -28,6 +28,7 @@
#include <linux/linkage.h>
#include <linux/init.h>
#include <linux/ptrace.h>
+#include <linux/kallsyms.h>
#include <asm/setup.h>
#include <asm/fpu.h>
@@ -102,56 +103,47 @@ asmlinkage void buserr_c(struct frame *f
force_sig(SIGSEGV, current);
}
-
int kstack_depth_to_print = 48;
-void show_stack(struct task_struct *task, unsigned long *stack)
+static void __show_stack(struct task_struct *task, unsigned long *stack)
{
unsigned long *endstack, addr;
- extern char _start, _etext;
+ unsigned long *last_stack;
int i;
- if (!stack) {
- if (task)
- stack = (unsigned long *)task->thread.ksp;
- else
- stack = (unsigned long *)&stack;
- }
+ if (!stack)
+ stack = (unsigned long *)task->thread.ksp;
addr = (unsigned long) stack;
endstack = (unsigned long *) PAGE_ALIGN(addr);
printk(KERN_EMERG "Stack from %08lx:", (unsigned long)stack);
for (i = 0; i < kstack_depth_to_print; i++) {
- if (stack + 1 > endstack)
+ if (stack + 1 + i > endstack)
break;
if (i % 8 == 0)
printk("\n" KERN_EMERG " ");
- printk(" %08lx", *stack++);
+ printk(" %08lx", *(stack + i));
}
printk("\n");
- printk(KERN_EMERG "Call Trace:");
- i = 0;
- while (stack + 1 <= endstack) {
- addr = *stack++;
- /*
- * If the address is either in the text segment of the
- * kernel, or in the region which contains vmalloc'ed
- * memory, it *may* be the address of a calling
- * routine; if so, print it so that someone tracing
- * down the cause of the crash will be able to figure
- * out the call path that was taken.
- */
- if (((addr >= (unsigned long) &_start) &&
- (addr <= (unsigned long) &_etext))) {
- if (i % 4 == 0)
- printk("\n" KERN_EMERG " ");
- printk(" [<%08lx>]", addr);
- i++;
- }
+#ifdef CONFIG_FRAME_POINTER
+ printk(KERN_EMERG "Call Trace:\n");
+
+ last_stack = stack - 1;
+ while (stack <= endstack && stack > last_stack) {
+
+ addr = *(stack + 1);
+ printk(KERN_EMERG " [%08lx] ", addr);
+ print_symbol(KERN_CONT "%s\n", addr);
+
+ last_stack = stack;
+ stack = (unsigned long *)*stack;
}
printk("\n");
+#else
+ printk(KERN_EMERG "CONFIG_FRAME_POINTER disabled, no symbolic call trace\n");
+#endif
}
void bad_super_trap(struct frame *fp)
@@ -298,19 +290,47 @@ asmlinkage void set_esp0(unsigned long s
current->thread.esp0 = ssp;
}
-
/*
* The architecture-independent backtrace generator
*/
void dump_stack(void)
{
- unsigned long stack;
-
- show_stack(current, &stack);
+ /*
+ * We need frame pointers for this little trick, which works as follows:
+ *
+ * +------------+ 0x00
+ * | Next SP | -> 0x0c
+ * +------------+ 0x04
+ * | Caller |
+ * +------------+ 0x08
+ * | Local vars | -> our stack var
+ * +------------+ 0x0c
+ * | Next SP | -> 0x18, that is what we pass to show_stack()
+ * +------------+ 0x10
+ * | Caller |
+ * +------------+ 0x14
+ * | Local vars |
+ * +------------+ 0x18
+ * | ... |
+ * +------------+
+ */
+
+ unsigned long *stack;
+
+ stack = (unsigned long *)&stack;
+ stack++;
+ __show_stack(current, stack);
}
-
EXPORT_SYMBOL(dump_stack);
+void show_stack(struct task_struct *task, unsigned long *stack)
+{
+ if (!stack && !task)
+ dump_stack();
+ else
+ __show_stack(task, stack);
+}
+
#ifdef CONFIG_M68KFPU_EMU
asmlinkage void fpemu_signal(int signal, int code, void *addr)
{
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] m68knommu: add pretty back strace
2008-05-01 2:16 [PATCH] m68knommu: add pretty back strace Greg Ungerer
@ 2008-05-02 19:27 ` Paulo Marques
2008-05-02 21:10 ` Sebastian Siewior
0 siblings, 1 reply; 5+ messages in thread
From: Paulo Marques @ 2008-05-02 19:27 UTC (permalink / raw)
To: Greg Ungerer; +Cc: torvalds, akpm, gerg, linux-kernel
Greg Ungerer wrote:
> From: Sebastian Siewior <bigeasy@linutronix.de>
>
> With this patch and
> CONFIG_FRAME_POINTER=y
> CONFIG_KALLSYMS=y
> The backtrace shows resolved function names and their numeric
> address.
This is really not my area, but this patch reminds me of all the dwarf2
unwinder on x86 that caused so many problems in the beginning...
> [...]
> +#ifdef CONFIG_FRAME_POINTER
> + printk(KERN_EMERG "Call Trace:\n");
> +
> + last_stack = stack - 1;
> + while (stack <= endstack && stack > last_stack) {
> +
> + addr = *(stack + 1);
> + printk(KERN_EMERG " [%08lx] ", addr);
> + print_symbol(KERN_CONT "%s\n", addr);
> +
> + last_stack = stack;
> + stack = (unsigned long *)*stack;
> }
> printk("\n");
> +#else
> + printk(KERN_EMERG "CONFIG_FRAME_POINTER disabled, no symbolic call trace\n");
You could probably fall back to the old method in this case, no?
Also, if the stack is slightly corrupted on the top, the new method
might just bail out without giving any indication about the path that
lead there, when instead it could also fall back to the old method.
--
Paulo Marques - www.grupopie.com
"Feed the hungry, save the whales, free the mallocs!"
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] m68knommu: add pretty back strace
2008-05-02 19:27 ` Paulo Marques
@ 2008-05-02 21:10 ` Sebastian Siewior
2008-05-05 19:21 ` Paulo Marques
0 siblings, 1 reply; 5+ messages in thread
From: Sebastian Siewior @ 2008-05-02 21:10 UTC (permalink / raw)
To: Paulo Marques; +Cc: Greg Ungerer, torvalds, akpm, gerg, linux-kernel
* Paulo Marques | 2008-05-02 20:27:57 [+0100]:
> Greg Ungerer wrote:
>> From: Sebastian Siewior <bigeasy@linutronix.de>
>> With this patch and
>> CONFIG_FRAME_POINTER=y
>> CONFIG_KALLSYMS=y
>> The backtrace shows resolved function names and their numeric
>> address.
>
> This is really not my area, but this patch reminds me of all the dwarf2
> unwinder on x86 that caused so many problems in the beginning...
>
>> [...]
>> +#ifdef CONFIG_FRAME_POINTER
>> + printk(KERN_EMERG "Call Trace:\n");
>> +
>> + last_stack = stack - 1;
>> + while (stack <= endstack && stack > last_stack) {
>> +
>> + addr = *(stack + 1);
>> + printk(KERN_EMERG " [%08lx] ", addr);
>> + print_symbol(KERN_CONT "%s\n", addr);
>> +
>> + last_stack = stack;
>> + stack = (unsigned long *)*stack;
>> }
>> printk("\n");
>> +#else
>> + printk(KERN_EMERG "CONFIG_FRAME_POINTER disabled, no symbolic call
>> trace\n");
>
> You could probably fall back to the old method in this case, no?
The old method printed every value from stack which was in the text
range (you didn't get modules AFAIK). This might be the caller as well a
function pointer as argument as well something else. I tried to find to
find a pattern without frame pointers but I had no luck. I thing the
caller fixed the stack frame or something.
Greg did not complain about removing it. If you or others want the old
method in case of no frame pointers I can send a patch.
> Also, if the stack is slightly corrupted on the top, the new method might
> just bail out without giving any indication about the path that lead there,
> when instead it could also fall back to the old method.
You mean by slightly that the first caller ORed the address with
something? In that case we don't return safely. I don't know how I could
find out the right time for a fallback (in case of slightly corrupted
stack).
> Paulo Marques - www.grupopie.com
Sebastian
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] m68knommu: add pretty back strace
2008-05-02 21:10 ` Sebastian Siewior
@ 2008-05-05 19:21 ` Paulo Marques
2008-05-06 4:52 ` Greg Ungerer
0 siblings, 1 reply; 5+ messages in thread
From: Paulo Marques @ 2008-05-05 19:21 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: Greg Ungerer, torvalds, akpm, gerg, linux-kernel
Sebastian Siewior wrote:
> * Paulo Marques | 2008-05-02 20:27:57 [+0100]:
>
>> Greg Ungerer wrote:
>>> From: Sebastian Siewior <bigeasy@linutronix.de>
>>> With this patch and
>>> CONFIG_FRAME_POINTER=y
>>> CONFIG_KALLSYMS=y
>>> The backtrace shows resolved function names and their numeric
>>> address.
>> This is really not my area, but this patch reminds me of all the dwarf2
>> unwinder on x86 that caused so many problems in the beginning...
>>
>>> [...]
>>> +#ifdef CONFIG_FRAME_POINTER
>>> + printk(KERN_EMERG "Call Trace:\n");
>>> +
>>> + last_stack = stack - 1;
>>> + while (stack <= endstack && stack > last_stack) {
>>> +
>>> + addr = *(stack + 1);
>>> + printk(KERN_EMERG " [%08lx] ", addr);
>>> + print_symbol(KERN_CONT "%s\n", addr);
>>> +
>>> + last_stack = stack;
>>> + stack = (unsigned long *)*stack;
>>> }
>>> printk("\n");
>>> +#else
>>> + printk(KERN_EMERG "CONFIG_FRAME_POINTER disabled, no symbolic call
>>> trace\n");
>> You could probably fall back to the old method in this case, no?
> The old method printed every value from stack which was in the text
> range (you didn't get modules AFAIK). This might be the caller as well a
> function pointer as argument as well something else. I tried to find to
> find a pattern without frame pointers but I had no luck. I thing the
> caller fixed the stack frame or something.
> Greg did not complain about removing it. If you or others want the old
> method in case of no frame pointers I can send a patch.
Having output garbled with "false positive" addresses, but that have the
"true positives" in between is better than no output at all.
>> Also, if the stack is slightly corrupted on the top, the new method might
>> just bail out without giving any indication about the path that lead there,
>> when instead it could also fall back to the old method.
> You mean by slightly that the first caller ORed the address with
> something?
Or more commonly, a buffer overflow... (or underflow, depending on how
the stack grows)
> In that case we don't return safely. I don't know how I could
> find out the right time for a fallback (in case of slightly corrupted
> stack).
I was imagining you would get a page fault where you'd show a stack
trace, but that's on a MMU processor. With no MMU I guess you don't get
a chance to do that :(
As I said before, this is really not my area. I just remember that a
very similar change in x86 was a real pain, and wanted to make sure that
everyone here was aware of that.
--
Paulo Marques - www.grupopie.com
"Who is general Failure and why is he reading my disk?"
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] m68knommu: add pretty back strace
2008-05-05 19:21 ` Paulo Marques
@ 2008-05-06 4:52 ` Greg Ungerer
0 siblings, 0 replies; 5+ messages in thread
From: Greg Ungerer @ 2008-05-06 4:52 UTC (permalink / raw)
To: Paulo Marques; +Cc: Sebastian Siewior, torvalds, akpm, linux-kernel
Hi Paulo,
Paulo Marques wrote:
> Sebastian Siewior wrote:
>> * Paulo Marques | 2008-05-02 20:27:57 [+0100]:
>>
>>> Greg Ungerer wrote:
>>>> From: Sebastian Siewior <bigeasy@linutronix.de>
>>>> With this patch and
>>>> CONFIG_FRAME_POINTER=y
>>>> CONFIG_KALLSYMS=y
>>>> The backtrace shows resolved function names and their numeric
>>>> address.
>>> This is really not my area, but this patch reminds me of all the
>>> dwarf2 unwinder on x86 that caused so many problems in the beginning...
>>>
>>>> [...]
>>>> +#ifdef CONFIG_FRAME_POINTER
>>>> + printk(KERN_EMERG "Call Trace:\n");
>>>> +
>>>> + last_stack = stack - 1;
>>>> + while (stack <= endstack && stack > last_stack) {
>>>> +
>>>> + addr = *(stack + 1);
>>>> + printk(KERN_EMERG " [%08lx] ", addr);
>>>> + print_symbol(KERN_CONT "%s\n", addr);
>>>> +
>>>> + last_stack = stack;
>>>> + stack = (unsigned long *)*stack;
>>>> }
>>>> printk("\n");
>>>> +#else
>>>> + printk(KERN_EMERG "CONFIG_FRAME_POINTER disabled, no symbolic
>>>> call trace\n");
>>> You could probably fall back to the old method in this case, no?
>> The old method printed every value from stack which was in the text
>> range (you didn't get modules AFAIK). This might be the caller as well a
>> function pointer as argument as well something else. I tried to find to
>> find a pattern without frame pointers but I had no luck. I thing the
>> caller fixed the stack frame or something.
>> Greg did not complain about removing it. If you or others want the old
>> method in case of no frame pointers I can send a patch.
>
> Having output garbled with "false positive" addresses, but that have the
> "true positives" in between is better than no output at all.
Yes that is a reasonable argument.
But you still get the full stack hex dump, so all the raw information
is there still. Just not in a decoded form. (I tended to use the raw
dump more often myself anyway).
>>> Also, if the stack is slightly corrupted on the top, the new method
>>> might just bail out without giving any indication about the path that
>>> lead there, when instead it could also fall back to the old method.
>> You mean by slightly that the first caller ORed the address with
>> something?
>
> Or more commonly, a buffer overflow... (or underflow, depending on how
> the stack grows)
>
>> In that case we don't return safely. I don't know how I could
>> find out the right time for a fallback (in case of slightly corrupted
>> stack).
>
> I was imagining you would get a page fault where you'd show a stack
> trace, but that's on a MMU processor. With no MMU I guess you don't get
> a chance to do that :(
>
> As I said before, this is really not my area. I just remember that a
> very similar change in x86 was a real pain, and wanted to make sure that
> everyone here was aware of that.
I would have no problem with the original full symbolic decode
being in as a fall back for the non FRAME_POINTER case.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-05-06 4:52 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-01 2:16 [PATCH] m68knommu: add pretty back strace Greg Ungerer
2008-05-02 19:27 ` Paulo Marques
2008-05-02 21:10 ` Sebastian Siewior
2008-05-05 19:21 ` Paulo Marques
2008-05-06 4:52 ` Greg Ungerer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox