From: Jiri Olsa <jolsa@redhat.com>
To: Song Liu <songliubraving@fb.com>
Cc: open list <linux-kernel@vger.kernel.org>,
Kernel Team <Kernel-team@fb.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"acme@kernel.org" <acme@kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"namhyung@kernel.org" <namhyung@kernel.org>
Subject: Re: [RFC v2 1/2] perf: support build BPF skeletons with perf
Date: Thu, 3 Dec 2020 23:20:57 +0100 [thread overview]
Message-ID: <20201203222057.GD3613628@krava> (raw)
In-Reply-To: <709375F7-A386-415B-926E-0A19783D09A5@fb.com>
On Tue, Dec 01, 2020 at 10:47:59PM +0000, Song Liu wrote:
SNIP
> >> # As per kernel Makefile, avoid funny character set dependencies
> >> unexport LC_ALL
> >> @@ -735,7 +737,8 @@ prepare: $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)common-cmds.h archheaders $(drm_ioc
> >> $(x86_arch_prctl_code_array) \
> >> $(rename_flags_array) \
> >> $(arch_errno_name_array) \
> >> - $(sync_file_range_arrays)
> >> + $(sync_file_range_arrays) \
> >> + bpf-skel
> >
> > I think the 'prepare' target is misused already with other stuff,
> > there's generated bpf_counter.c dependency on util/bpf_skel/bpf_prog_profiler.skel.h
> > in util/.bpf_counter.o.cmd, that should triger the build no?
>
> This doesn't work for me. Once bpf-skel is removed from "prepare", we hit
> compilation error before util/.bpf_counter.o.cmd is generated.
ok, I'll check on that with your new version
SNIP
> >> +submake_extras := feature_display=0
> >> +
> >> +$(SKEL_TMP_OUT):
> >> + $(Q)$(MKDIR) -p $@
> >> +
> >> +$(BPFTOOL): | $(SKEL_TMP_OUT)
> >> + CFLAGS= $(MAKE) $(submake_extras) -C ../bpf/bpftool \
> >> + OUTPUT=$(SKEL_TMP_OUT)/ bootstrap
> >> +
> >> +$(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(BPFOBJ) | $(SKEL_TMP_OUT)
> >> + $(call QUIET_CLANG, $@)
> >> + $(Q)$(CLANG) -g -O2 -target bpf -c $(filter util/bpf_skel/%.bpf.c,$^) -o $@ && \
> >> + $(LLVM_STRIP) -g $@
> >> +
> >> +$(SKEL_OUT)/%.skel.h: $(SKEL_TMP_OUT)/%.bpf.o | $(BPFTOOL)
> >> + $(call QUIET_GENSKEL, $@)
> >
> > is there a reason to use call in here? you could define QUIET_GENSKEL
> > to use $@ and use it the same way as we use the rest of QUIET_* stuf
> > in Makefile.perf
>
> I am not following here. $(CALL QUIET_xx) was used for QUIET_CLEAN and
> QUIET_INSTALL in Makefile.perf. What is the preferred pattern here?
right it's QUIET_CLEAN and QUIET_INSTALL because they need argument,
QUIET_GENSKEL uses $@, which is used directly in other QUIET_* macros
>
> >
> >> new file mode 100644
> >> index 0000000000000..5263e9e6c5d83
> >> --- /dev/null
> >> +++ b/tools/perf/util/bpf_skel/.gitignore
> >> @@ -0,0 +1,3 @@
> >> +# SPDX-License-Identifier: GPL-2.0-only
> >> +.tmp
> >> +*.skel.h
> >> \ No newline at end of file
> >> diff --git a/tools/perf/util/bpf_skel/dummy.bpf.c b/tools/perf/util/bpf_skel/dummy.bpf.c
> >> new file mode 100644
> >> index 0000000000000..492a43a851deb
> >> --- /dev/null
> >> +++ b/tools/perf/util/bpf_skel/dummy.bpf.c
> >
> > hum, what's the reason for dummy skeleton? it just adds
> > time to compilation no?
>
> It is mostly to test 1/2 of the set works fine. I guess we can remove
> it in 2/2?
so it needs to be there otherwise the compilation fails?
I'll check your new version
thanks,
jirka
next prev parent reply other threads:[~2020-12-03 22:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-01 7:36 [RFC v2 0/2] Introduce perf-stat -b for BPF programs Song Liu
2020-12-01 7:36 ` [RFC v2 1/2] perf: support build BPF skeletons with perf Song Liu
2020-12-01 20:54 ` Jiri Olsa
2020-12-01 22:47 ` Song Liu
2020-12-03 22:20 ` Jiri Olsa [this message]
2020-12-01 7:36 ` [RFC v2 2/2] perf-stat: enable counting events for BPF programs Song Liu
2020-12-01 20:16 ` [RFC v2 0/2] Introduce perf-stat -b " Jiri Olsa
2020-12-01 20:43 ` Song Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201203222057.GD3613628@krava \
--to=jolsa@redhat.com \
--cc=Kernel-team@fb.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=songliubraving@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox