[Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building

[James Hilliard]

On Sun, Jun 19, 2022 at 9:20 AM Arnout Vandecappelle <arnout at 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
> >> <buildroot at 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
>