On Fri, Oct 20, 2023 at 05:39:25PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Oct 19, 2023 at 03:48:56PM -0700, Manu Bretelle escreveu:
> > On Thu, Oct 19, 2023 at 06:08:33PM -0300, Arnaldo Carvalho de Melo wrote:
> > > I wonder how to improve the current situation to detect these kinds of
> > > problems in the future, i.e. how to notice that some file needed by some
> > > Makefile, etc got removed or that some feature test fails because some
> > > change in the test .c files makes them fail and thus activates fallbacks
> > > like the one above :-\
>
> > I think it is tricky. Specifically to this situation, some CI could try to build
> > the different combinaison of bpftool and check the features through the build
> > `bpftool --version`.
>
> Right, if the right packages are installed, we expect to get some
> bpftool build output, if that changes after some patch, flag it.
>
> Does bpftool have something like:
>
> ⬢[acme@toolbox perf-tools-next]$ perf version --build-options
> perf version 6.6.rc1.ga8dd62d05e56
> dwarf: [ on ] # HAVE_DWARF_SUPPORT
> dwarf_getlocations: [ on ] # HAVE_DWARF_GETLOCATIONS_SUPPORT
> syscall_table: [ on ] # HAVE_SYSCALL_TABLE_SUPPORT
> libbfd: [ OFF ] # HAVE_LIBBFD_SUPPORT
> debuginfod: [ on ] # HAVE_DEBUGINFOD_SUPPORT
> libelf: [ on ] # HAVE_LIBELF_SUPPORT
> libnuma: [ on ] # HAVE_LIBNUMA_SUPPORT
> numa_num_possible_cpus: [ on ] # HAVE_LIBNUMA_SUPPORT
> libperl: [ on ] # HAVE_LIBPERL_SUPPORT
> libpython: [ on ] # HAVE_LIBPYTHON_SUPPORT
> libslang: [ on ] # HAVE_SLANG_SUPPORT
> libcrypto: [ on ] # HAVE_LIBCRYPTO_SUPPORT
> libunwind: [ on ] # HAVE_LIBUNWIND_SUPPORT
> libdw-dwarf-unwind: [ on ] # HAVE_DWARF_SUPPORT
> zlib: [ on ] # HAVE_ZLIB_SUPPORT
> lzma: [ on ] # HAVE_LZMA_SUPPORT
> get_cpuid: [ on ] # HAVE_AUXTRACE_SUPPORT
> bpf: [ on ] # HAVE_LIBBPF_SUPPORT
> aio: [ on ] # HAVE_AIO_SUPPORT
> zstd: [ on ] # HAVE_ZSTD_SUPPORT
> libpfm4: [ on ] # HAVE_LIBPFM
> libtraceevent: [ on ] # HAVE_LIBTRACEEVENT
> bpf_skeletons: [ on ] # HAVE_BPF_SKEL
> ⬢[acme@toolbox perf-tools-next]$
>
> ?
>
It has
$ ./tools/bpf/bpftool/bpftool --version -j | jq .features
{
"libbfd": false,
"llvm": true,
"skeletons": true,
"bootstrap": false
}
Maybe Quentin knows of something else.
> > This is actually a test that I run internally to make sure our build has some
> > feature enabled.
> > This is actually tested by bpftool in the GH CI:
> > https://github.com/libbpf/bpftool/blob/main/.github/workflows/build.yaml#L62
>
> > As a matter of fact, it would not have been detected because that CI uses a
> > different Makefile.feature.
>
> > Quentin and I were talking offline how we could improve bpftool CI at diff time.
> > This is an example where it would have helped :)
> >
> > > I'll get this merged in my perf-tools-fixes-for-v6.6 that I'll submit
> > > tomorrow to Linus, thanks for reporting!
> > >
> > > I'll add your:
> > >
> > > Reported-by: Manu Bretelle <chantr4@xxxxxxxxx>
> > >
> > > And:
> > >
> > > Fixes: 56b11a2126bf2f42 ("perf bpf: Remove support for embedding clang for compiling BPF events (-e foo.c)")
> > >
> > > Ok?
>
> > SGTM. Thanks for the quick turnaround.
>
> > Reviewed-by: Manu Bretelle <chantr4@xxxxxxxxx>
>
> You're welcome, thanks for the detailed report, the patch was just sent
> to Linus.
>
> - Arnaldo
