perf cc/perf bpf was: Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Tue, Jun 21, 2016 at 02:12:38PM +0800, Wangnan (F) escreveu:
> On 2016/6/21 0:22, Alexei Starovoitov wrote:
> > On Mon, Jun 20, 2016 at 11:38:18AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Jun 20, 2016 at 11:29:13AM +0800, Wangnan (F) escreveu:
> > > > On 2016/6/17 0:48, Arnaldo Carvalho de Melo wrote:
> > > 	perf bcc -c foo.c

> > > Looks so much simpler and similar to an existing compile source code
> > > into object file workflow (gcc's, any C compiler) that I think it would
> > > fit in the workflow being discussed really nicely.

> > I'm hopeful that eventually we'll be able merge iovisor/bcc project
> > with perf, so would be good to reserve 'perf bcc' command for that
> > future use. Also picking a different name for compiling would be less
> > confusing to users who already familiar with bcc. Instead we can use:

> > perf bpfcc foo.c -o foo.o
> > perf cc foo.c
> > perf compile foo.c
 
> I think finally we should make perf independent with LLVM runtime.
> I suggest 'perf bpf' subcommand to deal with all BPF related things,
> include compiling, configuration and potential cache.

I think 'bpf' is tied to a detail, the fact that right now it generates
ELF binaries that are loaded via sys_bpf(), but it is not necessarily a
filter (the F in BPF) nor deals exclusively with packets, etc.

What we're doing here? Getting a .c file and turning it into a .o file
suitable to be run. And doing it thru a compiler, why not call it that,
i.e. 'cc'?

If we end up supporting the compilation of .c code to some binary format
to attach to some other event, perhaps not even in the kernel or via
sys_bpf, we could just add that other format to 'perf cc', again reusing
the existing model of 'cc' generating ELF, a.out, etc.

- Arnaldo