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

[James Hilliard]

On Mon, Jun 20, 2022 at 12:27 PM Arnout Vandecappelle <arnout at mind.be> wrote:
>
>
>
> On 20/06/2022 11:17, James Hilliard wrote:
> > On Mon, Jun 20, 2022 at 12:45 AM Arnout Vandecappelle <arnout at mind.be> wrote:
> >>
> >>
> >>
> >> On 20/06/2022 01:19, James Hilliard wrote:
> >>> 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
> >>
> >>    We do it for GCC, so we can do something similar for clang.
> >>
> >>> 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.
> >>
> >>    For GCC, the host toolchain is completely unrelated to the target toolchain.
> >> With clang, it's true that it's possible to use the target compiler for host
> >> builds as well, but don't we still need binutils? So in my mind, there would be
> >> a separate host clang toolchain and target clang toolchain.
> >
> > BPF is kinda weird...for both clang and GCC. It's sorta a separate
> > architecture in
> > the compiler...but is also sorta not architecture specific in what it
> > builds for.
>
>   Ah! I understood from Shahab's message that host-clang was used to build a
> host tool that is then used to build the target package. But it's actually used
> as a cross-compiler then, just with a different target.
>
>
> >>> 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.
> >>
> >>    Unfortunately your series is rather large and has no Reviewed or Acked by
> >> tags... So it tends to languish on patchwork.
> >
> > The tested-by for the v12 series ended up in the wrong thread I think:
> > https://lore.kernel.org/buildroot/BN2P110MB16408DC4537E54EF7ECC7906F21A9@BN2P110MB1640.NAMP110.PROD.OUTLOOK.COM/
>
>   All right, I'll look into it!
>
>
> >>>>     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.
> >>
> >>    Although I'm usually in favour of automatic dependencies, in this case I'd say
> >> it's worth adding an explicit config option.
> >>
> >>
> >>> There's some early GCC support for co-re in 12.1 which I was experimenting with
> >>
> >>    But then it would depend on both host and target GCC >= 12...
> >
> > I thought we don't support GCC on the target.
>
>   Yeah, terminology is difficult... With "host gcc" I meant "the gcc that builds
> for the host, i.e. the native gcc" and with "target gcc" I meant "the gcc that
> builds for the target, i.e. the cross-gcc".
>
> > We would essentially have a 2 architecture cross-toolchain(one real
> > target arch, and the
> > BPF virtual architecture compiler/assemblers and such).
>
>
>   Yeah, that makes sense... So the idea is that we build GCC with bpf support,
> similar like how we build it with Fortran support, right?

Well it's a bit different in how we build the toolchain, but it's more
or less used like
a separate language when building packages that need BPF.

I sent an initial series adding BPF support:
https://lore.kernel.org/buildroot/20220809094109.2279598-1-james.hilliard1@gmail.com/

>
>
>   Regards,
>   Arnout
>
> >>> 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).
> >>
> >>    Ouch, so we still can't reuse the existing host toolchain for the host parts?
> >> then it doesn't help that much, does it?
> >
> > We can create a GCC toolchain that can target both BPF and the normal target
> > architecture...but it's sorta a strange multiarch style toolchain.
> >
> >>
> >>    Regards,
> >>    Arnout
> >>
> >>>
> >>> 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
> >>>>