When build kernel with Clang [1]:
$ make CC=clang loongson3_defconfig
$ make CC=clang
there exists the following error:
Checking missing-syscalls for O32
CALL scripts/checksyscalls.sh
error: ABI 'o32' is not supported on CPU 'mips64r2'
make[1]: *** [Kbuild:48: missing-syscalls] Error 1
make: *** [arch/mips/Makefile:419: archprepare] Error 2
This is a known bug [2] with Clang, as Simon Atanasyan said,
"There is no plan on support O32 for MIPS64 due to lack of
resources".
It is not a good idea to remove this config due to GCC works
well, so add comment to point out this bug and suggest the
users to remove CONFIG_MIPS32_O32=y in defconfig when build
kernel with Clang.
[1] https://www.kernel.org/doc/html/latest/kbuild/llvm.html
[2] https://bugs.llvm.org/show_bug.cgi?id=38063
Signed-off-by: Tiezhu Yang <[email protected]>
---
arch/mips/configs/loongson3_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig
index 0e79f81..cacf9dd 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -35,6 +35,9 @@ CONFIG_NUMA=y
CONFIG_SMP=y
CONFIG_HZ_256=y
CONFIG_KEXEC=y
+# Please remove CONFIG_MIPS32_O32=y when build with Clang
+# due to "ABI 'o32' is not supported on CPU 'mips64r2'",
+# https://bugs.llvm.org/show_bug.cgi?id=38063
CONFIG_MIPS32_O32=y
CONFIG_MIPS32_N32=y
CONFIG_VIRTUALIZATION=y
--
2.1.0
On Thu, 4 Mar 2021, Tiezhu Yang wrote:
> This is a known bug [2] with Clang, as Simon Atanasyan said,
> "There is no plan on support O32 for MIPS64 due to lack of
> resources".
Huh? Is that a joke? From the o32 psABI's point of view a MIPS64 CPU is
exactly the same as a MIPS32 one (for whatever ISA revision), so there's
nothing to support there really other than the CPU/ISA name.
As much as I dislike all the hacks the Clang community seems to come up
with for the shortcomings of their tool there has to be a saner workaround
available rather than forcibly disabling support for the o32 ABI with
CONFIG_64BIT kernels, but the report is missing the compiler invocation
line triggering the issue (V=1 perhaps?), which should be included with
any commit description anyway, so I can't suggest anything based on the
limited information provided.
Maciej
?? 2021/3/5 ????7:08, Maciej W. Rozycki ะด??:
> On Thu, 4 Mar 2021, Tiezhu Yang wrote:
>
>> This is a known bug [2] with Clang, as Simon Atanasyan said,
>> "There is no plan on support O32 for MIPS64 due to lack of
>> resources".
>
> Huh? Is that a joke? From the o32 psABI's point of view a MIPS64 CPU is
> exactly the same as a MIPS32 one (for whatever ISA revision), so there's
> nothing to support there really other than the CPU/ISA name.
Clang treat MIPS32 as a different backend so we may need some extra
effort....
TBH it is a toolchain issue and kernel workaround seems bogus.
From my point view we can "s/mips64r2/mips32r2" when doing syscall checks
to workaround clang issue instead of disable it for kernel.
Thanks.
- Jiaxun
>
> As much as I dislike all the hacks the Clang community seems to come up
> with for the shortcomings of their tool there has to be a saner workaround
> available rather than forcibly disabling support for the o32 ABI with
> CONFIG_64BIT kernels, but the report is missing the compiler invocation
> line triggering the issue (V=1 perhaps?), which should be included with
> any commit description anyway, so I can't suggest anything based on the
> limited information provided.
>
> Maciej
>
On Fri, 5 Mar 2021, Jiaxun Yang wrote:
> > Huh? Is that a joke? From the o32 psABI's point of view a MIPS64 CPU is
> > exactly the same as a MIPS32 one (for whatever ISA revision), so there's
> > nothing to support there really other than the CPU/ISA name.
>
> Clang treat MIPS32 as a different backend so we may need some extra effort....
>
> TBH it is a toolchain issue and kernel workaround seems bogus.
>
> From my point view we can "s/mips64r2/mips32r2" when doing syscall checks
> to workaround clang issue instead of disable it for kernel.
I had something like this in mind, but obviously that has to be done in a
consistent manner across all the possible 64-bit `-march=...' selections,
as I suppose that is where the problem comes from. So we'd have to handle
things like say `octeon'. But I'd like to see the invocation line to be
sure (I could try and check that myself, but I don't have Clang and it's
the patch submitter's job anyway to explain things and not the reviewer's
to chase them).
Maybe we could cheat and wire everything to a single setting so as to
keep the hack to the minimum, but we need to know what the right setting
is from the Clang people.
NB only MIPS IV is special in that it has 32-bit extensions beyond MIPS
III but not a corresponding 32-bit ISA. The corresponding 32-bit ISA for
MIPS III is MIPS II, and obviously all the modern MIPS ISAs come in pairs.
So it's only MIPS IV where o32 may want special support (at the hardware
level the ISA had the CP0.Status.XX bit to control the ISA extensions),
and I guess only a few people care at this point, though some are present
on this mailing list.
Maciej