Re: [PATCH] arm64: Disable big endian builds with clang

From: Mark Brown <broonie@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Tri Vo <trong@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	clang-built-linux@googlegroups.com,
	Matt Hart <matthew.hart@linaro.org>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: Disable big endian builds with clang
Date: Wed, 7 Aug 2019 16:29:34 +0100	[thread overview]
Message-ID: <20190807152934.GF4048@sirena.co.uk> (raw)
In-Reply-To: <20190807135618.GF54191@lakrids.cambridge.arm.com>

[-- Attachment #1.1: Type: text/plain, Size: 1904 bytes --]

On Wed, Aug 07, 2019 at 02:56:19PM +0100, Mark Rutland wrote:
> On Wed, Aug 07, 2019 at 02:05:27PM +0100, Mark Brown wrote:

> > As far as I know this has been broken for as long as we tried building
> > and booting big endian kernels in clang.  The compile works fine, it's
> > just that the resulting binary doesn't seem to be working so well.

> I've just had a go, and it works for me. Log below from a BE busybox,
> but I also have a BE buildroot filesystem working.

Copying Matt who can actually look at the jobs getting submitted.  The
rootfs we're using should be:

	https://storage.kernelci.org/images/rootfs/buildroot/arm64be/

> From your log, it looks like the kernel is trying to launch init via
> binfmt_misc, using binfmt-464c. It could be that the file is corrupted
> somehow, or something's going wrong with binfmt. I haven't delved into
> that.

You can see the exact image being used in the reports I linked:

	https://storage.kernelci.org/next/master/next-20190730/arm64/defconfig+CONFIG_CPU_BIG_ENDIAN=y/clang-8/Image

> Are you using the right filesystem (and is the kernel definitely
> identifying itself as BE in the Image header flags)?

I'm assured that we're using the same rootfs as the GCC BE builds, sadly
neither of the labs that has boards configured to allow BE boots gives
enough access for me to verify that personally.

> This could be a dynamic loader issue -- my busybox is statically linked,
> and I'm not sure about my buildroot filesystem.

> This could be platform-specific; I'm booting under a KVM/QEMU VM on
> ThunderX2, using virtio-block for storage.

It's failing on every single platform we're trying, that's not as many
as it should be but it's still a bunch of physical platforms and like I
say the variable is the compiler.  A platform issue that only manifests
in the handover to userspace on multiple boards doesn't seem like the
most likely avenue.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel