Re: Android 11 clang toochain: kernel 5.18 build error with 32 bit target

From: Arnd Bergmann <arnd@arndb.de>
To: Mauro Rossi <issor.oruam@gmail.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
	Arnd Bergmann <arnd@arndb.de>,
	 Chih-Wei Huang <cwhuang@android-x86.org>,
	clang-built-linux <llvm@lists.linux.dev>
Subject: Re: Android 11 clang toochain: kernel 5.18 build error with 32 bit target
Date: Tue, 26 Apr 2022 14:21:16 +0200	[thread overview]
Message-ID: <CAK8P3a2vHuRB1vkjVkKaNxr3Ptfv3UBS0scsShQPxY46_xh9kA@mail.gmail.com> (raw)
In-Reply-To: <CAEQFVGYpPaE3cCxUBaiT97GU1i4Nr6yJdv6mU1kiCxqkLSMfBQ@mail.gmail.com>

On Mon, Apr 25, 2022 at 9:13 PM Mauro Rossi <issor.oruam@gmail.com> wrote:
> I have checked also with kernel-5.17 and the same build error is
> happening also there, so it is not due to commit 34737e2698 ("uaccess: add generic
> __{get,put}_kernel_nofault")

Ok, that's good to know, thanks for checking! I suspect the problem is
using a slightly too-old prerelease build of clang, where the released
clang-11 build had the asm-goto-with-output feature enabled. Maybe
we should just increase the minimum version to clang-11.1 for the
kernel to keep others from running into this issue.

> In the attachments the defconfig files I am using to build ARCH=x86
> kernel target

I see that the 5.17 kernel is configured using gcc-4.9.0, which is another
known broken prerelease compiler that used to ship with Android.
If you want to use gcc, I would recommend at least gcc-9 these days,
though 4.9.4 was supposed to work until recently.

> As far as I remember x86 32bit target has always been tricky, maybe I
> am doing some gross mistake, if this is the case I apologize in advance

I think generally speaking x86-32 support in the kernel is declining,
and anyone who has a 64-bit capable CPU should migrate to a 64-bit
kernel with CONFIG_COMPAT=y to run the 32-bit user space.

If you have users on early Atom or Pentium 4 processors, or something
even older, that of course won't help you, but I suspect that eventually
those will get too hard to support anyway.

We have similar problems on ARM, where running 32-bit kernels on
64-bit hardware comes with even more problems. In both cases though,
the kernels likely miss features and errata fixes for modern CPUs,
and as soon as you want to use a substantial amount of memory.
either physical RAM (more than 768MB gets you into highmem
with its own problems) or virtual address space (32-bit tasks on
a 32-bit kernel can use between 1GB and 3GB depending on
configuration, compared to 4GB on 64-bit kernels).

The cost of running a 64-bit kernel in comparison is losing around
20 to 30MB of RAM for kernel-internal data structures, which is a bit
annoying but much less than the cost of running a 64-bit Android.

       Arnd