From: "Török Edwin" <edwintorok@gmail.com>
To: "Frédéric Weisbecker" <fweisbec@gmail.com>
Cc: mingo@elte.hu, srostedt@redhat.com, a.p.zijlstra@chello.nl,
sandmann@daimi.au.dk, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] Add support for userspace stacktraces in tracing/iter_ctrl
Date: Sun, 26 Oct 2008 09:03:43 +0200 [thread overview]
Message-ID: <4904164F.5090006@gmail.com> (raw)
In-Reply-To: <c62985530810252105k3bce2339k5a49c09fa502ac67@mail.gmail.com>
On 2008-10-26 06:05, Frédéric Weisbecker wrote:
> Hi Török,
>
> I just read a bit more those two patches about user stack tracing.
> Note that despite the recent changes on the tracing Api
> (ring buffer and other stuff), it still applies well, with some little
> hunks. But it needs some updates to support the last changes.
>
> I adapted the patch and it builds well, but I didn't tested yet.
> However, some parts are "architecture dependent", I guess these
> special pieces would find a better place in the arch directory. So it
> would let a proper and seperated implementation.
>
Hi,
The stacktrace code itself is in the arch directory, did I miss anything
else that should belong there?
arch/x86/kernel/stacktrace.c | 57 +++++++++++++++++++++++++++++++++++
include/linux/stacktrace.h | 8 +++++
> And most arch implement a stacktrace implementation, even if yours
> involve special operations such as copy_from_user, I wonder if the
> already established code couldn't be reused for your needs.
>
I think it would make sense to use oprofile's code of user stacktracing,
there is a backtrace
operation in 'struct oprofile_operations'. Perhaps that could be
extended so that non-oprofile code can call it?
[currently it uses oprofile_add_trace to store the stacktrace]
Best regards,
--Edwin
next prev parent reply other threads:[~2008-10-26 7:04 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-12 13:11 [PATCH 0/4] ftrace: add userspace stacktrace support and semaphore-latency tracer Török Edwin
2008-10-12 13:12 ` Török Edwin
2008-10-12 13:12 ` [PATCH 1/4] Add support for userspace stacktraces in tracing/iter_ctrl Török Edwin
2008-10-12 13:31 ` Frédéric Weisbecker
2008-10-12 13:53 ` Török Edwin
2008-10-13 8:02 ` Frédéric Weisbecker
2008-10-26 4:05 ` Frédéric Weisbecker
2008-10-26 7:03 ` Török Edwin [this message]
2008-10-26 15:06 ` Frédéric Weisbecker
2008-10-26 13:15 ` Frank Ch. Eigler
2008-10-26 13:29 ` Peter Zijlstra
2008-10-26 13:38 ` Török Edwin
2008-10-26 13:49 ` Frank Ch. Eigler
2008-10-27 16:03 ` Ingo Molnar
2008-10-27 16:16 ` Török Edwin
2008-10-12 13:12 ` [PATCH 2/4] Identify which executable object the userspace address belongs to Török Edwin
2008-10-12 13:12 ` [PATCH 3/4] add tracepoints in rwsem Török Edwin
2008-10-12 13:12 ` [PATCH 4/4] Implement semaphore latency tracer Török Edwin
2008-10-12 19:13 ` Peter Zijlstra
2008-10-12 20:10 ` Török Edwin
2008-10-22 15:28 ` Ingo Molnar
2008-10-22 15:41 ` Török Edwin
2008-10-22 15:48 ` Ingo Molnar
2008-10-22 17:22 ` Peter Zijlstra
2008-10-22 17:25 ` Török Edwin
2008-10-12 18:25 ` [PATCH 0/4] ftrace: add userspace stacktrace support and semaphore-latency tracer Steven Rostedt
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=4904164F.5090006@gmail.com \
--to=edwintorok@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sandmann@daimi.au.dk \
--cc=srostedt@redhat.com \
/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.