Message-ID: <55671195.5040501@huawei.com>
Date:	Thu, 28 May 2015 21:01:09 +0800
From:	He Kuang <hekuang@...wei.com>
To:	Alexei Starovoitov <ast@...mgrid.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	<wangnan0@...wei.com>, <paulus@...ba.org>,
	<a.p.zijlstra@...llo.nl>, <mingo@...hat.com>, <acme@...nel.org>,
	<namhyung@...nel.org>, <jolsa@...nel.org>, <dsahern@...il.com>,
	<brendan.d.gregg@...il.com>, <daniel@...earbox.net>
CC:	<lizefan@...wei.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 09/15] perf probe: Support $params without
 debuginfo



On 2015/5/27 23:30, Alexei Starovoitov wrote:
> On 5/26/15 7:27 PM, He Kuang wrote:
>> hi, Alexei
>>
>> On 2015/5/27 1:50, Alexei Starovoitov wrote:
>>> On 5/25/15 1:33 AM, He Kuang wrote:
>>>> Right, I learnt regparm(3) is mandatory in x86_32, according to rules,
>>>> the first three args will go to regparm(ax, dx, cx). But we should not
>>>> refer arg1~3 to ax, dx, cx because of 64bit parameters (other reasons?).
>>>>
>>>> Consider this keyword is used for generating bpf prologue which fetches
>>>> formal parameters when no debuginfo is provided, for this purpose, we can:
>>>> 	1) We just help fetch the $regs or $regparms(If the keyword is
>>>> $regparms, ax/dx/cx is fetched, nothing related to args) to bpf arglists
>>>> and leave the rest things to bpf prog writer.
>>>>
>>>> 	2) Keep that on platforms like x86_64 and skip this feature on
>>>> platforms like x86_32.
>>>>
>>>> or any other suggestions?
>>>
>>> Single argument like $regparam or whatever name cannot work on all
>>> architectures, that's why in the very beginning I suggested
>>> 'func(long, char, void*)' syntax to describe arguments when debuginfo
>>> is not available. Calling convention for scalars is simple enough on
>>> all major architectures. x64_64 - trivial, i64_32 - a bit more involved,
>>> but simple enough so that list of types of arguments is enough to figure
>>> out which register or register pair or stack should be used to fetch
>>> argN.
>>>
>>>
>> As Masami has reminded,  the use of 'asmlinkage' forces regparm=0, and
>> we can't destinguish them without debuginfo, so 'func(long, char,
>> void*)' syntax not work in everywhere.
>>
>> In fact, all the context infos are there in bpf prog(pt_regs in arg1).
>> To the non-debuginfo case, without the help of prologue, user steps
>> following flow to fetch params:
>>
>> 1. pt_regs(arg1) + architecture => calling regs
>>
>> 2. calling regs + function prototype(SEC) + gcc attributes(like
>> asmlinkage) => formal parameters
>>
>>    '$regparms' do the 1st step, though not a full workaround. But for the
>> lack of gcc attributes, it seems we can't do the 2nd step. Any ideas?
> 
> 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.

> will be able to write programs that are architecture independent.
> We already have 'struct pt_regs *' and $regparams don't buy us
> anything extra. It may be useful for generic kprobe, but not for bpf.
> 
> 

--
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