From: "Steven J. Magnani" <steve@digidescorp.com>
To: microblaze-uclinux@itee.uq.edu.au
Cc: monstr@monstr.eu, linux-kernel@vger.kernel.org,
"Steven J. Magnani" <steve@digidescorp.com>
Subject: [RFC] microblaze: Support FRAME_POINTER for better backtrace
Date: Thu, 25 Feb 2010 14:13:29 -0600 [thread overview]
Message-ID: <1267128809-22749-1-git-send-email-steve@digidescorp.com> (raw)
Add a FRAME_POINTER option and when it is enabled, use frame pointers
to walk the stack during a backtrace dump. This eliminates printout of
confusing "function calls" corresponding to stack values that look like they
might be return addresses, but aren't.
This patch is dependent upon
[PATCH] microblaze: Begin stack dump with caller of dump_stack()
I'm not certain whether the MMU compiler generates frame pointers the same
way as the noMMU compiler I am using. I'm also not sure what all the
ramifications of providing FRAME_POINTER are. It looks like tracing
functionality makes use of it. Need someone familiar with these areas
to comment on the patch.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
---
diff -uprN a/arch/microblaze/Kconfig.debug b/arch/microblaze/Kconfig.debug
--- a/arch/microblaze/Kconfig.debug 2010-02-25 13:52:30.000000000 -0600
+++ b/arch/microblaze/Kconfig.debug 2010-02-25 13:52:49.000000000 -0600
@@ -26,4 +26,11 @@ config DEBUG_BOOTMEM
depends on DEBUG_KERNEL
bool "Debug BOOTMEM initialization"
+config FRAME_POINTER
+ bool "Use frame pointers"
+ default n
+ help
+ If you say N here, the resulting kernel will be slightly smaller and
+ faster. However, stack dumps will be much harder to interpret.
+
endmenu
diff -uprN a/arch/microblaze/kernel/traps.c b/arch/microblaze/kernel/traps.c
--- a/arch/microblaze/kernel/traps.c 2010-02-25 13:50:00.000000000 -0600
+++ b/arch/microblaze/kernel/traps.c 2010-02-25 13:51:11.000000000 -0600
@@ -8,6 +8,7 @@
* for more details.
*/
+#include <generated/autoconf.h>
#include <linux/kernel.h>
#include <linux/kallsyms.h>
#include <linux/module.h>
@@ -44,7 +45,7 @@ void show_trace(struct task_struct *task
printk(KERN_NOTICE "\n");
#endif
while (!kstack_end(stack)) {
- addr = *stack++;
+ addr = *stack;
/*
* If the address is either in the text segment of the
* kernel, or in the region which contains vmalloc'ed
@@ -55,6 +56,13 @@ void show_trace(struct task_struct *task
*/
if (kernel_text_address(addr))
print_ip_sym(addr);
+
+#if defined(CONFIG_FRAME_POINTER)
+ /* Fetch the caller's frame pointer */
+ stack = (unsigned long *) stack[7];
+#else
+ stack++;
+#endif
}
printk(KERN_NOTICE "\n");
next reply other threads:[~2010-02-25 20:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-25 20:13 Steven J. Magnani [this message]
2010-02-26 8:06 ` Michal Simek
2010-02-26 16:49 ` Steven J. Magnani
2010-03-01 1:43 ` Paul Mundt
2010-03-01 21:26 ` Steven J. Magnani
2010-03-10 22:51 ` Steven J. Magnani
2010-03-11 0:05 ` Paul Mundt
2010-03-01 23:04 ` Paul Mundt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1267128809-22749-1-git-send-email-steve@digidescorp.com \
--to=steve@digidescorp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=microblaze-uclinux@itee.uq.edu.au \
--cc=monstr@monstr.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome