On Sun, Jun 19, 2022 at 9:20 AM Arnout Vandecappelle <arn...@mind.be> wrote: > > > > On 16/06/2022 10:11, Shahab Vahedi wrote: > > On 6/16/22 01:27, James Hilliard wrote: > >> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot > >> <buildr...@buildroot.org> wrote: > >>> > >>> On 6/14/22 19:14, Arnout Vandecappelle wrote: > >>>> > >>>> On 14/06/2022 11:31, Shahab Vahedi wrote: > >>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11 > >>>> > >>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC > >>>> is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on > >>>> the Buildroot command line? I'm not sure if we are really interested in > >>>> carrying fixes for such exotic and not-really-supported situations... > >>> > >>> No, I don't do any sort of trickery to build bpftool on my end. The > >>> bootstrapping, if becomes available for your configuration, uses clang > >>> and only clang. I tried to explain this in v4 of the patch [1], the > >>> second paragraph of the commit message. > >> > >> I think clang/llvm support isn't going to work correctly yet since we only > >> have > >> version 9.0.1, there's a series bumping to version 11.1.0 that should fix > >> that: > >> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585 > >> > >> Minimum clang/llvm version for libbpf co-re is version 10: > >> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere > > > > You're right about the clang version, but it doesn't have anything to do > > with Buildroot's clang. The build process uses the clang that is installed > > on the host. For Debian bullseye, that is clang 11. > > > > To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet > > the bootstrap part of bpftool, uses the x86 clang of the Debian machine. > > > Hm, that smells like we actually want to build host-clang (after updating it > to 11.1.0 of course) so that we are sure a known version of clang is used. > Possibly with a check-host-clang check to avoid building it if the installed > clang is good enough.
Dealing with multiple external clang versions may be a bit tricky and difficult to test properly, we don't really want to use the system clang/llvm although clang/llvm external toolchain support may be desirable here as those could be tested by the autobuilders. It would be good to get clang/llvm updated soon as systemd is now using bpf for some service security/isolation features that we currently aren't able to support due to clang/llvm being too old. > > And we probably want a user-visible option to enable co-re then, because > it's > going to be expensive to build. We may want to make llvm/clang part of the pre-built toolchains eventually, but for now I'd say we should just conditionally enable co-re here if we are already building a clang/llvm toolchain. There's some early GCC support for co-re in 12.1 which I was experimenting with as well which may reduce the need for a llvm/clang toolchain for co-re. The GCC toolchain BPF support build process is a bit complex however as one needs to sorta do a hybrid multitarget build with GCC and binutils since GCC treats BPF as a separate target(and since GCC along with the binutils GAS assembler don't natively handle multi-target toolchain builds themselves). I have an experimental branch for that here: https://github.com/buildroot/buildroot/compare/master...jameshilliard:ebpf I'll try and clean that up a bit once the GCC 12.1 series it is based on is merged: https://patchwork.ozlabs.org/project/buildroot/list/?series=302389 > > Regards, > Arnout > _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
