Re: [RFC PATCH v6 25/32] perf tools: Add 'bpf.' config section to perf default config

From: Alexei Starovoitov
Date: Tue Jun 09 2015 - 21:09:52 EST


On 6/9/15 5:47 PM, Wangnan (F) wrote:


On 2015/6/10 7:43, Alexei Starovoitov wrote:
On 6/8/15 10:50 PM, Wang Nan wrote:
perf_bpf_config() is added to parse 'bpf' section in perf config file.
Following is an example:

[bpf]
clang-path = /llvm/bin/x86_64-linux-clang"
llc-path = /llvm/bin/x86_64-linux-llc"
clang-opt = "-nostdinc -isystem /llvm/lib/clang/include
-I/kernel/arch/x86/include ..."
llc-opt = ""

a section to specify -I flags to compile prog.c is useful,
but users shouldn't be populating it manually for kernel headers.
How about adding a script that can figure out $(LINUXINCLUDE)
automatically ?
You can even invoke such flag detector from perf via something like:
f = open /tmpdir/Makefile
fprintf(f, "obj-y := dummy.o\n");
fprintf(f, "$(obj)/%%.o: $(src)/%%.c\n");
fprintf(f, "\t@echo -n \"$(NOSTDINC_FLAGS) $(LINUXINCLUDE)
$(EXTRA_CFLAGS)\" > %s\n", cachefile);
snprintf(cmd, "make -s -C /lib/modules/%s/build M=%s dummy.o",
uts_release, tmpdir);
system(cmd);
read flags from cachefile and cache it for the future.
...
or as independent script that populates .perfconfig


That's cool, but could I implement it later? Introducing such stuffs

I think --clang-opts shouldn't be introduced without
automatic flag finder. Ease of use is important.

also introduces
a lot of trouble tasks:

1. Dependency on make and kernel build. We should search make and kbuild
dir dynamically
and also gives users the right to specify them by theirselves. A lot
of configuration
options should be appended: --make-path=/path/to/make
--kbuild-dir=kernel/build/dir
in cmdline and
[kbuild]
make_path = /path/to/make
kbuild_dir = /path/to/kbuild
in .perfconfig.

they're not mandatory. If 'make' is not in a PATH, it's dead end.
kernel build is very likely installed in /lib/modules/

2. Selection of architectures. Although currently we want it to work
only when we dynamically
compile a script, I think finally we should consider cross compiling
bpf objects. Then cmdline
generation becomes complex. Also, --arch and [kbuild.arch] should
also be introduced.

that's a rare use case. This one can be added later.

3. Kernel dependency. Consider if kernel decides to change its interface...

change what interface? 'make M=' ? sure. then lots of scripts will be
broken.

I think currently we can pop some messages to let user know how to get
include dirs manually,
let further patches to do it for them automatically.

P.S.

Have you tested your Makefile? It doesn't work for me:

works as a charm:
$ cat /home/ast/ff/Makefile
obj-y := dummy.o

$(obj)/%.o: $(src)/%.c
@echo -n "$(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS)" > /tmp/xxx
$ make -s -C /w/net-next/bld_x64 M=/home/ast/ff dummy.o
$ cat /tmp/xxx
-nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.7/include -I../arch/x86/include -Iarch/x86/include/generated/uapi -Iarch/x86/include/generated -I../include -Iinclude -I../arch/x86/include/uapi -Iarch/x86/include/generated/uapi -I../include/uapi -Iinclude/generated/uapi -include ../include/linux/kconfig.h

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/