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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20160620162208.GA67352@ast-mbp.thefacebook.com>
Date:	Mon, 20 Jun 2016 09:22:11 -0700
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	Arnaldo Carvalho de Melo <acme@...hat.com>
Cc:	"Wangnan (F)" <wangnan0@...wei.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	linux-kernel@...r.kernel.org, pi3orama@....com,
	David Ahern <dsahern@...il.com>,
	Namhyung Kim <namhyung@...il.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 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:
> > >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.
> 
> Not really, we may have as many as we like, given that they provide
> something useful, like I think is the case here.
> 
> Having to edit ~/.perfconfig, create a new section, a variable in it
> with a boolean value (at first, just reading the changeset comment, I
> thought I had to provide a directory where to store the objects
> "dumped"), to then use a tool to record a .c event, but not recording
> (use dry-run, which is useful to test the command line, etc), to then
> get, on the current directory, the end result looked to me a convoluted
> way to ask perf to compile the given .c file into a .o for later use.
> 
> Doing:
> 
> 	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