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 ...
[ message continues ]

This is really not my area, but this patch reminds me of all the dwarf2 

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!"
--

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
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
Sebastian
--

Having output garbled with "false positive" addresses, but that have the 

Or more commonly, a buffer overflow... (or underflow, depending on how 

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?"
--

Hi Paulo,


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

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
--