Re: [PATCH v1 1/4] perf parse-events: Remove BPF event support

[Quentin Monnet]

On 20/10/2023 23:37, Manu Bretelle wrote:
> 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.

Correct, this is what we do on the CI on the GitHub mirror (checking
that the mirrored version builds correctly, with the expected features).

>>
>> 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, or ldd on the binary (unless it was a static build). But "bpftool
version" should be enough to tell whether the LLVM disassembler is built
in or not, so we haven't needed something else so far.

Quentin