linux-kernel - Re: LLVM not detected in bpfutil due to LLVM 16 requiring c++17

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] [day] [month] [year] [list]

Date:   Fri, 14 Apr 2023 17:26:07 +0100
From:   Quentin Monnet <quentin@...valent.com>
To:     Nathan Chancellor <nathan@...nel.org>,
        No Name <xbjfk.github@...il.com>
Cc:     linux-kernel@...r.kernel.org, ndesaulniers@...gle.com,
        llvm@...ts.linux.dev, bpf@...r.kernel.org,
        Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: LLVM not detected in bpfutil due to LLVM 16 requiring c++17

Hi Nathan, Reagan, thanks for the report and CC,

2023-04-14 08:43 UTC-0700 ~ Nathan Chancellor <nathan@...nel.org>
> Hi Reagan,
> 
> On Fri, Apr 14, 2023 at 10:36:35PM +1200, No Name wrote:
>> This is my first time reporting a bug, so apologies if I get something wrong.
> 
> Thanks for the report! "See something, say something", even if it is not
> quite right out of the gate, we can get down to the bottom of it.
> 
>> In tools/build/feature/Makefile, line 342, the c++ std is set to
>> gnu++14, whereas LLVM 16 now requires c++17 to include the headers.
>> This results in the llvm feature being falsely disabled for bpfutil.
> 
> I cannot find any reference to bpfutil either in tree or when doing a
> web search, did you mean bpftool? I am going to assume yes, so I have
> gone ahead and added Quentin (the maintainer of bpftool in MAINTAINERS)
> and bpf@...r.kernel.org to the thread.
> 
>> Perhaps the --cxxflags, --ldflags and --libs options of llvm-config
>> should instead?
> 
> The tools system is pretty much Greek to me, so I am hoping someone else
> will have a better idea of what is going on and how to fix it.
> 
> For the record, I think I see the issue you are talking about on Fedora,
> which has clang-16, whereas I do not see the same issue on Arch Linux,
> which still has clang-15.
> 
>   $ clang --version | head -1
>   clang version 15.0.7
> 
>   $ make -C tools/bpf/bpftool -j(nproc) -s
> 
>   Auto-detecting system features:
>   ...                         clang-bpf-co-re: [ on  ]
>   ...                                    llvm: [ on  ]
>   ...                                  libcap: [ on  ]
>   ...                                  libbfd: [ on  ]
> 
> compared to
> 
>   $ clang --version | head -1
>   clang version 16.0.0 (Fedora 16.0.0-1.fc39)
> 
>   $ make -C tools/bpf/bpftool -j(nproc) -s
> 
>   Auto-detecting system features:
>   ...                         clang-bpf-co-re: [ on  ]
>   ...                                    llvm: [ OFF ]
>   ...                                  libcap: [ on  ]
>   ...                                  libbfd: [ on  ]
> 
> This is the output of tools/build/feature/test-llvm.make.output on my
> machine, which seems to confirm that the headers expect to be compiled
> with '-std=c++17', but that is just a superficial observation at this
> point.
> 

+Cc Arnaldo, as I believe perf uses the 'llvm' feature as well.

I noticed the same on my machine some time ago, but haven't investigated
yet. The error I get in test-llvm.make.output seems to be exactly the same.

I confirm I can fix detection by using '-std=c++17' instead. It looks
like the version was bumped earlier in commit d0d0f0c12461 ("tools: Bump
minimum LLVM C++ std to GNU++14").

Reagan's suggestion to use '$(shell $(LLVM_CONFIG) --cxxflags)' instead
of specifying the standard manually works as well on my setup, and looks
cleaner to me. But I'm not sure of the impact this change would have,
and if it might break other setups.

As far as I could find, perf and bpftool are the only users for this
feature?

Quentin