From: Alexei Starovoitov <ast@plumgrid.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
He Kuang <hekuang@huawei.com>,
wangnan0@huawei.com, paulus@samba.org, a.p.zijlstra@chello.nl,
mingo@redhat.com, acme@kernel.org, namhyung@kernel.org,
jolsa@kernel.org, dsahern@gmail.com, brendan.d.gregg@gmail.com,
daniel@iogearbox.net
Cc: lizefan@huawei.com, linux-kernel@vger.kernel.org,
cti.systems-productivity-manager.ts@hitachi.com
Subject: Re: [RFC PATCH v2 09/15] perf probe: Support $params without debuginfo
Date: Fri, 29 May 2015 18:27:52 -0700 [thread overview]
Message-ID: <55691218.6010303@plumgrid.com> (raw)
In-Reply-To: <5568FC5F.40504@hitachi.com>
On 5/29/15 4:55 PM, Masami Hiramatsu wrote:
> On 2015/05/29 15:30, He Kuang wrote:
>> hi, Alexei
>>
>> On 2015/5/29 2:10, Alexei Starovoitov wrote:
>>> On 5/28/15 6:01 AM, He Kuang wrote:
>>>>> I don't think you can break it down in two steps like this.
>>>>>> There is no such thing as 'calling regs'. x86_32 with ax,dx,cx
>>>>>> are not 'calling regs'. 64-bit values will be passed in a pair.
>>>>>> Only 'pt_regs + arch + func_proto + asmlinkage' makes sense
>>>>> >from the user point of view.
>>>>>> Adding 'asmlinkage' attr is also trivial.
>>>>>> 'func(long, char) asmlinkage' is easy to parse and the user
>>>> I think at this early stage, we could make our bpf variable
>>>> prologue work with debuginfo while keeping bpf 'SEC' syntax
>>>> consistent with original perf probe. After all, we can use
>>>> pt_regs directly or relay to perf-probe cache by Masami to deal
>>>> with non-debug cases.
>>>
>>> so you're saying you don't want to support non-debug case for now?
>>> Sure, as long as section name parser will be able to support
>>> 'func(long, char) asmlinkage' syntax in the future without breaking
>>> compatibility. I'm mostly interested in cases when debug info
>>> is not available at all. So perf-probe cache is of no use to me.
>>>
>>>
>>
>> Yes, that syntax do deal with the situation which current 'perf
>> probe' syntax not covered, so not only bpf prologue would benifit
>> from that, maybe we could try to let perf probe involve that.
>
> Hmm, then how about below syntax?
>
> perf probe x86_acpi_enter_sleep_state $regparams:asmlinkage(char)
>
> So, regparams has following synopsis.
>
> $regparams[:[asmlinkage|0-6]([u8|u16|u32|u64|ptr][,...])]
the number doesn't make sense in generic command. Only x86_32 plays
with calling convention. All other archs are not doing anything special
for asmlinkage.
I think the following is enough:
$regparams[[:asmlinkage]([u8|u16|u32|u64|ptr|char|short|long|
long long|void*][,...])]
asmlinkage most of the time won't be used and typical command will look
like: 'func=func $regparams(char, long, void*)'
which is ok for kprobe.
For bpf section name I would still prefer 'func(char, long, void*)'
since it's more concise, easier to remember, more similar to C declaration.
> Note that asmlinkage is a synonym of 0, and default depends on arch :)
> Some architecture ignores this part, e.g. x86_64 always uses regs.
> And it is automatically expanded to argX="%reg or $stackX".
>
> e.g.
> $regparams is expanded to
> arg1=%di arg2=%si arg3=%dx arg4=%cx arg5=%r8 arg6=%r9 (on x86_64)
> arg1=%ax arg2=%dx arg3=%cx arg4=$stack1 arg5=$stack2 arg6=$stack3 (on i386)
>
> $regparams:0 is expanded to
> arg1=%di arg2=%si arg3=%dx arg4=%cx arg5=%r8 arg6=%r9 (on x86_64)
> arg1=$stack1 arg2=$stack2 arg3=$stack3 arg4=$stack4 arg5=$stack5 arg6=$stack6 (on i386)
>
> $regparams:3(char,long) is expanded to
> arg1=%di:s8 arg2=%si:s64 (on x86_64)
> arg1=%ax:s8 arg2=%dx:s64 (on i386)
>
> How is this?
>
> Thank you,
>
>
next prev parent reply other threads:[~2015-05-30 1:27 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-24 8:27 [RFC PATCH v2 00/15] perf bpf: Probing with local variable He Kuang
2015-05-24 8:27 ` [RFC PATCH v2 01/15] perf tools: Add lib/bpf to cscope target list He Kuang
2015-05-24 8:27 ` [RFC PATCH v2 02/15] perf bpf: Support custom vmlinux path He Kuang
2015-05-24 8:27 ` [RFC PATCH v2 03/15] perf bpf: Save pt_regs info from debuginfo He Kuang
2015-05-24 13:31 ` Masami Hiramatsu
2015-05-25 7:38 ` He Kuang
2015-05-24 8:28 ` [RFC PATCH v2 04/15] perf tools: Add functions to get calling regs He Kuang
2015-05-24 8:28 ` [RFC PATCH v2 05/15] perf tools: Add pt_regs offsets and calling regs for x86 He Kuang
2015-05-24 8:28 ` [RFC PATCH v2 06/15] bpf tools: Add headers for generating bpf bytecode He Kuang
2015-05-24 8:28 ` [RFC PATCH v2 07/15] bpf tools: Convert arglist to bpf prologue He Kuang
2015-05-24 8:28 ` [RFC PATCH v2 08/15] bpf tools: Fetch calling regs to bpf arglist He Kuang
2015-05-24 8:28 ` [RFC PATCH v2 09/15] perf probe: Support $params without debuginfo He Kuang
2015-05-24 8:49 ` Masami Hiramatsu
2015-05-25 8:33 ` He Kuang
2015-05-25 12:22 ` Masami Hiramatsu
2015-05-25 12:46 ` Arnaldo Carvalho de Melo
2015-05-25 13:06 ` Masami Hiramatsu
2015-05-26 17:50 ` Alexei Starovoitov
2015-05-27 2:27 ` He Kuang
2015-05-27 11:43 ` Masami Hiramatsu
2015-05-27 15:30 ` Alexei Starovoitov
2015-05-28 13:01 ` He Kuang
2015-05-28 18:10 ` Alexei Starovoitov
2015-05-29 6:30 ` He Kuang
2015-05-29 23:55 ` Masami Hiramatsu
2015-05-30 1:27 ` Alexei Starovoitov [this message]
2015-05-30 7:01 ` Masami Hiramatsu
2015-05-24 8:28 ` [RFC PATCH v2 10/15] perf bpf: Process debuginfo for generating bpf prologue He Kuang
2015-05-24 8:28 ` [RFC PATCH v2 11/15] perf bpf: Synthesize vars to generate " He Kuang
2015-05-24 8:28 ` [RFC PATCH v2 12/15] perf bpf: Generate bpf prologue without debuginfo He Kuang
2015-05-24 8:28 ` [RFC PATCH v2 13/15] perf bpf: Combine bpf prologue and bpf prog He Kuang
2015-05-24 8:28 ` [RFC PATCH v2 14/15] samples/bpf: Add sample for testing bpf fetch args He Kuang
2015-05-24 8:28 ` [RFC PATCH v2 15/15] samples/bpf: Add sample for no-debuginfo case He Kuang
2015-05-26 17:53 ` Alexei Starovoitov
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=55691218.6010303@plumgrid.com \
--to=ast@plumgrid.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=brendan.d.gregg@gmail.com \
--cc=cti.systems-productivity-manager.ts@hitachi.com \
--cc=daniel@iogearbox.net \
--cc=dsahern@gmail.com \
--cc=hekuang@huawei.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=paulus@samba.org \
--cc=wangnan0@huawei.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;
as well as URLs for NNTP newsgroup(s).