[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <481B6B3D.9060200@grupopie.com>
Date: Fri, 02 May 2008 20:27:57 +0100
From: Paulo Marques <pmarques@...popie.com>
To: Greg Ungerer <gerg@...pgear.com>
CC: torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
gerg@...inux.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] m68knommu: add pretty back strace
Greg Ungerer wrote:
> From: Sebastian Siewior <bigeasy@...utronix.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!"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists