Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options
From: Wangnan (F)
Date: Sun Jun 19 2016 - 23:30:49 EST
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.