[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1225660694-19765-1-git-send-email-edwintorok@gmail.com>
Date: Sun, 2 Nov 2008 23:18:12 +0200
From: Török Edwin <edwintorok@...il.com>
To: mingo@...e.hu
Cc: srostedt@...hat.com, a.p.zijlstra@...llo.nl, sandmann@...mi.au.dk,
linux-kernel@...r.kernel.org, edwintorok@...il.com
Subject: Add support for userspace stacktraces in tracing/iter_ctrl [v2]
This patch series adds support for userstack tracing to ftrace.
I've tested it on x86_64.
Example usage:
mount -t debugfs nodev /sys/kernel/debug
cd /sys/kernel/debug/tracing
echo userstacktrace >iter_ctrl
echo sym-userobj >iter_ctrl
echo sched_switch >current_tracer
echo 1 >tracing_enabled
cat trace_pipe >/tmp/trace&
.... run application ...
echo 0 >tracing_enabled
cat /tmp/trace
a.out-1623 [000] 40874.465068: /root/a.out[+0x480] <-/root/a.out[+0
+x494] <- /root/a.out[+0x4a8] <- /lib/libc-2.7.so[+0x1e1a6]
If you just want the addresses don't use sym-userobj, but you should resolve the
address to an object before the process exits, otherwise you can't know which
object it belonged to, due to Address Space Layout Randomization (for libraries
at least).
To get meaningful results you'll need your app and
libs compiled with frame-pointers. This usually means rebuilding libc with
frame-pointers (your own app should have frame pointers by default, unless you
used -fomit-frame-pointer).
Another approach would be to use dwarf unwind info that works without frame
pointers (as userspace does it). There was a kernel/unwind.c around 2.6.19, but
it got removed, so I didn't look further at this possibility.
arch/x86/kernel/stacktrace.c | 57 +++++++++++++++++
Documentation/ftrace.txt | 16 ++++
kernel/trace/trace.c | 142 +++++++++++++++++++++++++++++++++++++++++++
kernel/trace/trace.h | 10 +++
include/linux/stacktrace.h | 8 ++
--
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