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

Mon Jun 20 11:27:21 PDT 2022

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?

  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
>>>>