From: Jason Wessel <jason.wessel@windriver.com>
To: lkml <linux-kernel@vger.kernel.org>, phil.el@wanadoo.fr
Cc: oprofile-list@lists.sourceforge.net
Subject: [PATCH][RFC] x86: oprofile 32bit stack traces on 64bit kernel
Date: Tue, 05 Feb 2008 10:20:52 -0600 [thread overview]
Message-ID: <47A88CE4.3070205@windriver.com> (raw)
There are multiple ways to write the same code, hence the reason this
is listed as an RFC patch. I wanted to provide a working fix to
account for the case of executing 32 bit and 64 bit user space code on
a 64 bit kernel.
-----CLIP HERE-------
Allow oprofile's backtrace to work on a 32bit user space thread when
running on a 64bit kernel.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
arch/x86/oprofile/backtrace.c | 40 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
--- a/arch/x86/oprofile/backtrace.c
+++ b/arch/x86/oprofile/backtrace.c
@@ -52,6 +52,39 @@ struct frame_head {
unsigned long ret;
} __attribute__((packed));
+
+#if defined(CONFIG_X86_64) && defined(CONFIG_IA32_EMULATION)
+struct frame_head32 {
+ unsigned int ebp;
+ unsigned int ret;
+} __attribute__((packed));
+
+static struct frame_head *
+dump_user_backtrace32(struct frame_head * head)
+{
+ struct frame_head32 bufhead[2];
+
+ /* Also check accessibility of one struct frame_head beyond */
+ if (!access_ok(VERIFY_READ, head, sizeof(bufhead)))
+ return NULL;
+ if (__copy_from_user_inatomic(bufhead, head, sizeof(bufhead)))
+ return NULL;
+ /* In a 32bit user space on a 64bit kernel the frame pointer and
+ * PC are not at the same place as in the 64 registers. This
+ * requires some casting and checks of the 32bit register values
+ * back to 64 pit pointers.
+ */
+ oprofile_add_trace(bufhead[0].ret);
+
+ /* frame pointers should strictly progress back up the stack
+ * (towards higher addresses) */
+ if (head >= (struct frame_head *)((unsigned long)bufhead[0].ebp))
+ return NULL;
+
+ return (struct frame_head *)((unsigned long)bufhead[0].ebp);
+}
+#endif
+
static struct frame_head *
dump_user_backtrace(struct frame_head * head)
{
@@ -85,7 +118,12 @@ x86_backtrace(struct pt_regs * const reg
&backtrace_ops, &depth);
return;
}
-
+#if defined(CONFIG_X86_64) && defined(CONFIG_IA32_EMULATION)
+ if (test_thread_flag(TIF_32BIT))
+ while (depth-- && head)
+ head = dump_user_backtrace32(head);
+ else
+#endif
while (depth-- && head)
head = dump_user_backtrace(head);
}
next reply other threads:[~2008-02-05 16:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-05 16:20 Jason Wessel [this message]
2008-02-07 16:57 ` [PATCH][RFC] x86: oprofile 32bit stack traces on 64bit kernel Arjan van de Ven
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=47A88CE4.3070205@windriver.com \
--to=jason.wessel@windriver.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oprofile-list@lists.sourceforge.net \
--cc=phil.el@wanadoo.fr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.