[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F75A2AA.4010604@hitachi.com>
Date: Fri, 30 Mar 2012 21:10:18 +0900
From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To: Stephane Eranian <eranian@...gle.com>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Jiri Olsa <jolsa@...hat.com>, acme@...hat.com, mingo@...e.hu,
paulus@...ba.org, cjashfor@...ux.vnet.ibm.com, fweisbec@...il.com,
gorcunov@...nvz.org, tzanussi@...il.com, mhiramat@...hat.com,
rostedt@...dmis.org, robert.richter@....com, fche@...hat.com,
linux-kernel@...r.kernel.org, yrl.pp-manager.tt@...achi.com
Subject: Re: [RFC 00/15] perf: Add backtrace post dwarf unwind
(2012/03/30 9:52), Stephane Eranian wrote:
> On Thu, Mar 29, 2012 at 5:44 PM, Peter Zijlstra <a.p.zijlstra@...llo.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@...achi.com
--
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