From: Frederic Weisbecker <fweisbec@gmail.com>
To: Jiri Olsa <jolsa@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>
Cc: acme@redhat.com, mingo@kernel.org, paulus@samba.org,
cjashfor@linux.vnet.ibm.com, eranian@google.com,
gorcunov@openvz.org, tzanussi@gmail.com, mhiramat@redhat.com,
robert.richter@amd.com, fche@redhat.com,
linux-kernel@vger.kernel.org, masami.hiramatsu.pt@hitachi.com,
drepper@gmail.com, asharma@fb.com
Subject: Re: [PATCH 02/17] perf: Add ability to attach registers dump to sample
Date: Mon, 21 May 2012 15:03:35 +0200 [thread overview]
Message-ID: <20120521130332.GB23687@somewhere> (raw)
In-Reply-To: <1335958638-5160-3-git-send-email-jolsa@redhat.com>
On Wed, May 02, 2012 at 01:37:03PM +0200, Jiri Olsa wrote:
> Introducing new sample_type bit PERF_SAMPLE_REGS. Once set,
> the sample_regs value determines the kind of registers going
> to be attached to the sample.
>
> Currently only user level registers are supported, specified by
> PERF_SAMPLE_REGS_USER sample_regs value. Meaning the register
> values of the user space context as it was before the user entered
> the kernel for whatever reason (syscall, irq, exception, or a PMI
> happening in userspace).
>
> When PERF_SAMPLE_REGS and PERF_SAMPLE_REGS_USER are set, the
> sample_regs_user bitmap lets a user choose a set of registers
> to dump for the sample. The layout of this bitmap is described
> in asm/perf_regs.h for archs that support register dump.
>
> This is going to be useful to bring Dwarf CFI based stack
> unwinding on top of samples.
>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> Signed-off-by: Jiri Olsa <jolsa@redhat.com>
> ---
> include/linux/perf_event.h | 25 ++++++++++-
> kernel/events/core.c | 98 ++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 121 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index ddbb6a9..6a8c974 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -130,8 +130,9 @@ enum perf_event_sample_format {
> PERF_SAMPLE_STREAM_ID = 1U << 9,
> PERF_SAMPLE_RAW = 1U << 10,
> PERF_SAMPLE_BRANCH_STACK = 1U << 11,
> + PERF_SAMPLE_REGS = 1U << 12,
Given that we have to provide a reg mask anyway, is this sample type
necessary? Zeroed mask means we don't want to record regs.
>
> - PERF_SAMPLE_MAX = 1U << 12, /* non-ABI */
> + PERF_SAMPLE_MAX = 1U << 13, /* non-ABI */
> };
>
> /*
> @@ -163,6 +164,15 @@ enum perf_branch_sample_type {
> PERF_SAMPLE_BRANCH_HV)
>
> /*
> + * Values for sample_regs when PERF_SAMPLE_REGS is set.
> + * Defines register set to be attached to the sample.
> + */
> +enum perf_sample_regs {
> + PERF_SAMPLE_REGS_USER = 1U << 0, /* user registers */
> + PERF_SAMPLE_REGS_MAX = 1U << 1, /* non-ABI */
> +};
If this is an enum, we won't be able to record multiple types of regs
(eg: user regs and event live regs) in a single sample.
> +
> +/*
> * The format of the data returned by read() on a perf event fd,
> * as specified by attr.read_format:
> *
> @@ -271,7 +281,16 @@ struct perf_event_attr {
> __u64 bp_len;
> __u64 config2; /* extension of config1 */
> };
> - __u64 branch_sample_type; /* enum branch_sample_type */
> + __u64 branch_sample_type; /* enum perf_branch_sample_type */
> +
> + __u64 sample_regs; /* enum perf_sample_regs */
> +
> + /*
> + * Arch specific mask for PERF_SAMPLE_REGS_USER setup.
> + * Defines set of user regs to dump on samples.
> + * See asm/perf_regs.h for details.
> + */
> + __u64 sample_regs_user;
We need to sort that out now. How do we handle normal/compat regs?
Do we want sample_regs_user_64 and sample_regs_user_32? Or can we
make it possible with a single field like above? Should we
expect more modes than just a simple native and compat? I don't
know much the world outside x86.
Would be nice to have the opinion of other people on this. Ingo, Peter, others?
Thanks.
next prev parent reply other threads:[~2012-05-21 13:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 11:37 [RFCv3 00/17] perf: Add backtrace post dwarf unwind Jiri Olsa
2012-05-02 11:37 ` [PATCH 01/17] perf: Unified API to record selective sets of arch registers Jiri Olsa
2012-05-02 11:37 ` [PATCH 02/17] perf: Add ability to attach registers dump to sample Jiri Olsa
2012-05-21 13:03 ` Frederic Weisbecker [this message]
2012-05-23 11:45 ` Jiri Olsa
2012-05-02 11:37 ` [PATCH 03/17] perf: Factor __output_copy to be usable with specific copy function Jiri Olsa
2012-05-02 11:37 ` [PATCH 04/17] perf: Add ability to attach user stack dump to sample Jiri Olsa
2012-05-21 13:19 ` Frederic Weisbecker
2012-05-02 11:37 ` [PATCH 05/17] perf: Add attribute to filter out user callchains Jiri Olsa
2012-05-02 11:37 ` [PATCH 06/17] perf, tool: Fix format string for x86-32 compilation Jiri Olsa
2012-05-11 6:45 ` [tip:perf/core] perf report: " tip-bot for Jiri Olsa
2012-05-02 11:37 ` [PATCH 07/17] perf, tool: Factor DSO symtab types to generic binary types Jiri Olsa
2012-05-02 11:37 ` [PATCH 08/17] perf, tool: Add interface to read DSO image data Jiri Olsa
2012-05-02 11:37 ` [PATCH 09/17] perf, tool: Add '.note' check into search for NOTE section Jiri Olsa
2012-05-02 11:37 ` [PATCH 10/17] perf, tool: Back [vdso] DSO with real data Jiri Olsa
2012-05-02 11:37 ` [PATCH 11/17] perf, tool: Add interface to arch registers sets Jiri Olsa
2012-05-02 11:37 ` [PATCH 12/17] perf, tool: Add libunwind dependency for dwarf cfi unwinding Jiri Olsa
2012-05-02 11:37 ` [PATCH 13/17] perf, tool: Support user regs and stack in sample parsing Jiri Olsa
2012-05-02 11:37 ` [PATCH 14/17] perf, tool: Support for dwarf cfi unwinding on post processing Jiri Olsa
2012-05-02 11:37 ` [PATCH 15/17] perf, tool: Support for dwarf mode callchain on perf record Jiri Olsa
2012-05-02 11:37 ` [PATCH 16/17] perf, tool: Add dso data caching Jiri Olsa
2012-05-02 11:37 ` [PATCH 17/17] perf, tool: Add dso data caching tests Jiri Olsa
2012-05-21 10:45 ` [RFCv3 00/17] perf: Add backtrace post dwarf unwind Jiri Olsa
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=20120521130332.GB23687@somewhere \
--to=fweisbec@gmail.com \
--cc=acme@redhat.com \
--cc=asharma@fb.com \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=drepper@gmail.com \
--cc=eranian@google.com \
--cc=fche@redhat.com \
--cc=gorcunov@openvz.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mhiramat@redhat.com \
--cc=mingo@kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
--cc=tzanussi@gmail.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.