From: WANG Rui <r@hev.cc>
To: nathan@kernel.org
Cc: arnd@arndb.de, chenhuacai@kernel.org, chenhuacai@loongson.cn,
guoren@kernel.org, jiaxun.yang@flygoat.com, kernel@xen0n.name,
linux-kernel@vger.kernel.org, lixuefeng@loongson.cn,
loongarch@lists.linux.dev, WANG Rui <r@hev.cc>
Subject: Re: [PATCH V4 14/14] LoongArch: Adjust build infrastructure for 32BIT/64BIT
Date: Fri, 24 Apr 2026 19:06:23 +0800 [thread overview]
Message-ID: <20260424110624.48510-1-r@hev.cc> (raw)
In-Reply-To: <20260423220647.GA3447678@ax162>
Hi Nathan,
>> diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
>> index 8d45b860fe56..47516aeea9d2 100644
>> --- a/arch/loongarch/Makefile
>> +++ b/arch/loongarch/Makefile
>...
>> @@ -62,9 +66,19 @@ ifneq ($(SUBARCH),$(ARCH))
>> endif
>> endif
>>
>> +ifdef CONFIG_32BIT
>> +ifdef CONFIG_32BIT_STANDARD
>> +ld-emul = $(32bit-emul)
>> +cflags-y += -march=la32v1.0 -mabi=ilp32s -mcmodel=normal
>> +else # CONFIG_32BIT_REDUCED
>> +ld-emul = $(32bit-emul)
>> +cflags-y += -march=la32rv1.0 -mabi=ilp32s -mcmodel=normal
>> +endif
>> +endif
>
> As a result of the above problem, I see
>
> clang: error: ignoring '-mabi=ilp32s' as it conflicts with that implied by '-msoft-float' (lp64s) [-Werror,-Woption-ignored]
> clang: error: ignoring '-mabi=ilp32s' as it conflicts with that implied by '-msoft-float' (lp64s) [-Werror,-Woption-ignored]
> clang: error: ignoring '-mabi=ilp32s' as it conflicts with that implied by '-msoft-float' (lp64s) [-Werror,-Woption-ignored]
>
> when building configurations that I expected to be 64-bit but had been
> turned into 32-bit ones with LLVM. This was also reported by the test
> robot with allnoconfig.
>
> https://lore.kernel.org/202604232041.ESJDwVG4-lkp@intel.com/
>
> Maybe some change is needed on the LLVM side?
The root cause is that scripts/Makefile.clang unconditionally sets
CLANG_TARGET_FLAGS_loongarch to loongarch64-linux-gnusf.
However, Clang with --target=loongarch64 does not support a 32-bit ABI.
LLVM clearly separates loongarch32 and loongarch64 targets.
Since CLANG_TARGET_FLAGS gets initialized before CONFIG is available, the
current setup effectively assumes that a 64-bit target must also handle
a 32-bit ABI. That assumption may not hold for LLVM, which models 32-bit
and 64-bit LoongArch as separate targets.
I have a workaround patch for now, though I’d appreciate suggestions if
there’s a cleaner fix.
diff --git a/Makefile b/Makefile
index 54e1ae602000..f03ff854014a 100644
--- a/Makefile
+++ b/Makefile
@@ -725,6 +725,10 @@ CC_VERSION_TEXT = $(subst $(pound),,$(shell LC_ALL=C $(CC) --version 2>/dev/null
RUSTC_VERSION_TEXT = $(subst $(pound),,$(shell $(RUSTC) --version 2>/dev/null))
PAHOLE_VERSION = $(shell $(srctree)/scripts/pahole-version.sh $(PAHOLE))
+ifdef need-config
+-include $(objtree)/include/config/auto.conf
+endif
+
ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
include $(srctree)/scripts/Makefile.clang
endif
diff --git a/scripts/Makefile.clang b/scripts/Makefile.clang
index b67636b28c35..1c4db2f6543e 100644
--- a/scripts/Makefile.clang
+++ b/scripts/Makefile.clang
@@ -4,7 +4,11 @@
CLANG_TARGET_FLAGS_arm := arm-linux-gnueabi
CLANG_TARGET_FLAGS_arm64 := aarch64-linux-gnu
CLANG_TARGET_FLAGS_hexagon := hexagon-linux-musl
+ifdef CONFIG_32BIT
+CLANG_TARGET_FLAGS_loongarch := loongarch32-linux-gnusf
+else
CLANG_TARGET_FLAGS_loongarch := loongarch64-linux-gnusf
+endif
CLANG_TARGET_FLAGS_m68k := m68k-linux-gnu
CLANG_TARGET_FLAGS_mips := mipsel-linux-gnu
CLANG_TARGET_FLAGS_powerpc := powerpc64le-linux-gnu
--
Thanks,
Rui
next prev parent reply other threads:[~2026-04-24 11:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-27 15:48 [PATCH V4 00/14] LoongArch: Add basic LoongArch32 support Huacai Chen
2025-11-27 15:48 ` [PATCH V4 01/14] LoongArch: Add atomic operations for 32BIT/64BIT Huacai Chen
2025-11-27 15:48 ` [PATCH V4 02/14] LoongArch: Add adaptive CSR accessors " Huacai Chen
2025-11-27 15:48 ` [PATCH V4 03/14] LoongArch: Adjust common macro definitions " Huacai Chen
2025-11-27 15:48 ` [PATCH V4 04/14] LoongArch: Adjust boot & setup " Huacai Chen
2025-11-27 15:48 ` [PATCH V4 05/14] LoongArch: Adjust memory management " Huacai Chen
2025-11-27 15:48 ` [PATCH V4 06/14] LoongArch: Adjust process " Huacai Chen
2025-11-27 15:48 ` [PATCH V4 07/14] LoongArch: Adjust time routines " Huacai Chen
2025-11-27 15:48 ` [PATCH V4 08/14] LoongArch: Adjust module loader " Huacai Chen
2025-11-27 15:48 ` [PATCH V4 09/14] LoongArch: Adjust system call " Huacai Chen
2025-11-27 15:48 ` [PATCH V4 10/14] LoongArch: Adjust user accessors " Huacai Chen
2025-11-27 15:48 ` [PATCH V4 11/14] LoongArch: Adjust misc routines " Huacai Chen
2025-11-27 15:48 ` [PATCH V4 12/14] LoongArch: Adjust VDSO/VSYSCALL " Huacai Chen
2025-11-27 15:48 ` [PATCH V4 13/14] LoongArch: Adjust default config files " Huacai Chen
2025-11-27 15:48 ` [PATCH V4 14/14] LoongArch: Adjust build infrastructure " Huacai Chen
2025-11-28 13:57 ` Arnd Bergmann
2025-11-28 14:27 ` Huacai Chen
2026-04-23 22:06 ` Nathan Chancellor
2026-04-24 4:14 ` Huacai Chen
2026-04-24 11:06 ` WANG Rui [this message]
2026-04-24 18:19 ` Nathan Chancellor
2026-04-25 2:29 ` hev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260424110624.48510-1-r@hev.cc \
--to=r@hev.cc \
--cc=arnd@arndb.de \
--cc=chenhuacai@kernel.org \
--cc=chenhuacai@loongson.cn \
--cc=guoren@kernel.org \
--cc=jiaxun.yang@flygoat.com \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=lixuefeng@loongson.cn \
--cc=loongarch@lists.linux.dev \
--cc=nathan@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.