From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Stephane Eranian <eranian@google.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Jiri Olsa <jolsa@redhat.com>,
acme@redhat.com, mingo@elte.hu, paulus@samba.org,
cjashfor@linux.vnet.ibm.com, fweisbec@gmail.com,
gorcunov@openvz.org, tzanussi@gmail.com, mhiramat@redhat.com,
rostedt@goodmis.org, robert.richter@amd.com, fche@redhat.com,
linux-kernel@vger.kernel.org, yrl.pp-manager.tt@hitachi.com
Subject: Re: [RFC 00/15] perf: Add backtrace post dwarf unwind
Date: Fri, 30 Mar 2012 21:10:18 +0900 [thread overview]
Message-ID: <4F75A2AA.4010604@hitachi.com> (raw)
In-Reply-To: <CABPqkBQbYs7JgGqfZD3ng6QMK0OpiVL=8gfyxn5aRgtYpPVjsw@mail.gmail.com>
(2012/03/30 9:52), Stephane Eranian wrote:
> On Thu, Mar 29, 2012 at 5:44 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>> On Thu, 2012-03-29 at 17:38 -0700, Stephane Eranian wrote:
>>> What I'd like to have is something similar to:
>>> attr->sample_type |= PERF_SAMPLE_REGS
>>> attr->sample_regs = EAX | EBX | EDI | ESI |.....
>>> attr->sample_reg_mode = { INTR, PRECISE, USER }
>>>
>>> Then in each sample for the event you dump the u64 values
>>> of the requested registers. The order is that of the enum
>>> enum regs {}. That enum is arch specific.
>>>
>>> When you are in precise mode on Intel, you extract the regs
>>> from PEBS. You already know the registers supported by PEBS
>>> so you can reject any request for unsupported regs.
>>>
>>> When you are in intr they you get the regs from pt_regs.
>>> The user mode case is taken care of by the this patch series
>>> already.
>>>
>>> I am not sure the sample_reg_mode needs to be a bitmask, i.e.,
>>> do we need the reg state for INTR+PRECISE or USER+INTR?
>>> But if so, then we would need attr->sample_regs[3] as not all
>>> registers may be available in each mode.
Would you have any good reason why we use INTR? Without PEBS,
it may mislead users because the register value can be changed
before interrupted. Personally, I would not like to use such
values for debugging use :)
So, I think this regs options may be good for the option of
PEBS events.
>> I'm really having trouble seeing how useful this is. You mentioned
>> sampling function arguments, but most samples would be in the middle of
>> functions where the regs are completely unrelated to arguments. Also
>> isn't the 'normal' C ABI passing args on stack rather than registers?
>>
> If you look at the SNB events, you'll see that br_inst_retired:near_call
> supports PEBS. The sample is taken at retirement of the call, i.e., the
> first instruction of the function, exactly where you want it to be.
>
> Unless I am mistaken, the x86_64 calling convention passes the first 6
> integer arguments in registers.
Right, almost all function arguments are passed by register on x86-64.
Hmm, this might be useful because it can trace function register-arguments
in user-space applications... even though it causes interruption on every
sampling calls...
Thanks,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2012-03-30 12:10 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-28 12:35 [RFC 00/15] perf: Add backtrace post dwarf unwind Jiri Olsa
2012-03-28 12:35 ` [PATCH 01/15] perf, tool: Fix the array pointer to follow event data properly Jiri Olsa
2012-03-28 12:35 ` [PATCH 02/15] uaccess: Add new copy_from_user_gup API Jiri Olsa
2012-03-28 12:35 ` [PATCH 03/15] perf: Unified API to record selective sets of arch registers Jiri Olsa
2012-03-30 12:51 ` Cyrill Gorcunov
2012-03-30 13:01 ` Jiri Olsa
2012-03-28 12:35 ` [PATCH 04/15] perf: Add ability to dump user regs Jiri Olsa
2012-03-28 14:01 ` Frank Ch. Eigler
2012-03-28 14:20 ` Jiri Olsa
2012-03-28 15:12 ` Frank Ch. Eigler
2012-03-28 16:01 ` Jiri Olsa
2012-03-28 16:10 ` Frederic Weisbecker
2012-03-28 16:06 ` Frederic Weisbecker
2012-03-28 17:02 ` Jiri Olsa
2012-03-28 21:41 ` Frederic Weisbecker
2012-03-30 14:42 ` Frederic Weisbecker
2012-03-28 12:35 ` [PATCH 05/15] perf: Add ability to dump part of the user stack Jiri Olsa
2012-03-28 12:35 ` [PATCH 06/15] perf: Add attribute to filter out user callchains Jiri Olsa
2012-03-28 12:35 ` [PATCH 07/15] perf, tool: Factor DSO symtab types to generic binary types Jiri Olsa
2012-03-28 12:35 ` [PATCH 08/15] perf, tool: Add interface to read DSO image data Jiri Olsa
2012-03-28 12:35 ` [PATCH 09/15] perf, tool: Add '.note' check into search for NOTE section Jiri Olsa
2012-03-28 12:35 ` [PATCH 10/15] perf, tool: Back [vdso] DSO with real data Jiri Olsa
2012-03-28 12:35 ` [PATCH 11/15] perf, tool: Add interface to arch registers sets Jiri Olsa
2012-03-28 12:35 ` [PATCH 12/15] perf, tool: Add libunwind dependency for dwarf cfi unwinding Jiri Olsa
2012-03-28 12:35 ` [PATCH 13/15] perf, tool: Support user regs and stack in sample parsing Jiri Olsa
2012-03-28 12:35 ` [PATCH 14/15] perf, tool: Support for dwarf cfi unwinding on post processing Jiri Olsa
2012-03-28 12:35 ` [PATCH 15/15] perf, tool: Support for dwarf mode callchain on perf record Jiri Olsa
2012-03-29 17:04 ` [RFC 00/15] perf: Add backtrace post dwarf unwind Stephane Eranian
2012-03-29 23:59 ` Peter Zijlstra
2012-03-30 0:38 ` Stephane Eranian
2012-03-30 0:44 ` Peter Zijlstra
2012-03-30 0:52 ` Stephane Eranian
2012-03-30 7:25 ` Robert Richter
2012-03-30 12:10 ` Masami Hiramatsu [this message]
2012-03-30 13:46 ` Ulrich Drepper
2012-03-30 17:54 ` Stephane Eranian
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=4F75A2AA.4010604@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=eranian@google.com \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=gorcunov@openvz.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=robert.richter@amd.com \
--cc=rostedt@goodmis.org \
--cc=tzanussi@gmail.com \
--cc=yrl.pp-manager.tt@hitachi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox