[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <f7069edc-a152-425f-afb1-8df326d0131c@app.fastmail.com>
Date: Thu, 29 Aug 2024 22:25:32 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Jason A . Donenfeld" <Jason@...c4.com>, linux-kernel@...r.kernel.org
Cc: "Nathan Chancellor" <nathan@...nel.org>
Subject: Re: odd endianness toolchains for crosstool
On Thu, Aug 29, 2024, at 17:51, Jason A. Donenfeld wrote:
> On Mon, Apr 25, 2022 at 03:39:27AM +0200, Jason A. Donenfeld wrote:
>
>
> I decided to give it another look, seeing if I could replace my musl.cc
> compilers with your crosstool ones.
>
> The actual changes required weren't so bad:
>
> https://git.zx2c4.com/wireguard-linux/commit/?h=update-toolchain
>
> But there's not universal success:
>
> x86_64 - good
> i386 - good
> arm - good
> armeb - MISSING
> aarch64 - good
> aarch64_be - MISSING
> mips - BROKEN (doesn't like -EB)
> mipsel - MISSING
> mips64 - BROKEN (doesn't like -EB)
> mips64el - MISSING
> powerpc64 - BROKEN (wrong powerpc ABI)
> powerpc64le - MISSING
> powerpc - BROKEN (builds but some binaries segfault)
> m68k - good
> riscv64 - good
> riscv32 - good
> s390 - BROKEN (should be called "s390x" instead)
> um - kinda broken (but not crosstool's problem)
>
> To try these, I've been running:
>
> ARCH=aarch64 make -C tools/testing/selftests/wireguard/qemu -j$(nproc)
>
> or similar, against this tree:
>
> $ git clone -b update-toolchain https://git.zx2c4.com/wireguard-linux/
>
> So it looks like it's not quite there, but not bad either. Just FYI in
> case you're interested.
I wonder if the ones you list as missing all work with Nathan's clang
builds from https://mirrors.edge.kernel.org/pub/tools/llvm/ instead.
As far as I can tell, the main missing bit here is libgcc, which
is not always built along with gcc for all possible targets.
The llvm replacement for libgcc is https://compiler-rt.llvm.org/,
and you may have to build that in addition to musl when you try it.
I don't know if compiler-rt also works with gcc, but if it does,
that should fix most of the ones that you report as failing above.
The only one that won't work at all is um because the x86 toolchain
is already unable to build a kernel for that.
Arnd
Powered by blists - more mailing lists