linux-kernel - Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 20 Jun 2016 11:29:13 +0800
From:	"Wangnan (F)" <wangnan0@...wei.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
CC:	<linux-kernel@...r.kernel.org>, <pi3orama@....com>,
	"Arnaldo Carvalho de Melo" <acme@...hat.com>,
	Alexei Starovoitov <ast@...nel.org>,
	Jiri Olsa <jolsa@...nel.org>
Subject: Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline
 options

On 2016/6/17 0:48, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jun 16, 2016 at 08:02:41AM +0000, Wang Nan escreveu:
>> With '--dry-run', 'perf record' doesn't do reall recording. Combine with
>> llvm.dump-obj option, --dry-run can be used to help compile BPF objects for
>> embedded platform.
> So these are nice and have value, but can we have a subcommand to do all
> this with an expressive name, Something like:
>
>    perf bpfcc foo.c -o foo
>
> or shorter:
>
>    perf bcc foo.c -o foo
>
> Just like one would use gcc or some other compiler to generate something
> for later use?

I'll try it today. I thought a subcommand require a bigger feature,
and wrapping clang is not big enough.

> That if called as:
>
>    perf bcc foo.c
>
> Would default to generating a foo.o file.
>
>    Then, later, one could use this as a event name, i.e.
>
>    trace --event foo
>
> Would, knowing that there is no event named "foo", look at the current
> directory (and in some other places perhaps) for a file named "foo" that
> was a bpf object file to use as it would a foo.c, shortcircuiting the
> bpf compilation code.
> If this was done instead:
>
>    trace --event foo.c
>
> And foo.c wasn't present, it would fallback to the behaviour described
> in the previous paragraph: look for a foo.o or foo bpf object file, etc.
>
> What do you think?

I'm not sure how many people can be benified from this feature. The only
advantage I can understand is we can skip the '.c', '.o' or '.bpf' suffix.

I guess what you really want is introducing something like buildid-cache for
BPF object. One can compile his/her BPF scriptlets into .o using 'perf 
bcc' and
insert it into cache, then he/her can use the resuling object without 
remembering
the path of it.

About fallback, if user explicitly uses '.o' or '.bpf' as suffix our 
parser can
be easier. Technically we need a boundary to split event name and 
configuration.
'.c', '.o' and '.bpf' are boundaries. In addition, is there any 
difference between
'-e mybpf' and '-e mybpf.bpf'? We can define that, when using '-e mybpf'
the search path whould be the BPF object cache, when using '-e 
mybpf.bpf' the
search path is current directory. It is acceptable, but why not make '-e 
mybpf.bpf'
search BPF object cache also?

Thank you.