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