On Mon, Jun 20, 2022 at 12:27 PM Arnout Vandecappelle <arn...@mind.be> wrote: > > > > On 20/06/2022 11:17, James Hilliard wrote: > > On Mon, Jun 20, 2022 at 12:45 AM Arnout Vandecappelle <arn...@mind.be> > > wrote: > >> > >> > >> > >> On 20/06/2022 01:19, James Hilliard wrote: > >>> 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 > >> > >> 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/bn2p110mb16408dc4537e54ef7ecc7906f2...@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.hillia...@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 > >>>> _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
