[PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Koakuma via B4 Relay]

Hello~

This changes the CFLAGS for building the SPARC kernel so that it can be
built with clang, as a follow up from the discussion in this thread:

https://lore.kernel.org/lkml/JAYB7uS-EdLABTR4iWZdtFOVa5MvlKosIrD_cKTzgeozCOGRM7lhxeLigFB1g3exX445I_W5VKB-tAzl2_G1zCVJRQjp67ODfsSqiZWOZ9o=@protonmail.com/T/#u

The changes are removal of various `-fcall-used-*` flags, and adding
clang target flags for SPARC:

- `-fcall-used-*` flags is removed as it is not supported in clang.
  Those should be safe to remove; the compiler will stop using the
  registers specified as temporaries, but it is a safe change wrt.
  the ABI. Assembly code can still use those registers as needed.
  A cursory look at the assembly generated by GCC 13.2 shows that
  the compiler was able to reallocate uses of those registers into
  other temporary registers without adding extra spills, so there
  should be no change in performance.

- More trivial is to add CLANG_TARGET_FLAGS for SPARC target.

Building with these changes still result in a working kernel,
at least for Sun T5120, Oracle T4-1, and qemu virtual machines.

On the LLVM side, the effort for building Linux/SPARC is tracked here:
https://github.com/llvm/llvm-project/issues/40792

Signed-off-by: Koakuma <koachan@protonmail.com>
---
Changes in v2:
- Remove the -mv8plus change; it will be handled on clang side:
  https://github.com/llvm/llvm-project/pull/98713
- Add CLANG_TARGET_FLAGS as suggested in v1 review.
- Link to v1: https://lore.kernel.org/r/20240620-sparc-cflags-v1-1-bba7d0ff7d42@protonmail.com

---
Koakuma (2):
      sparc/build: Remove all usage of -fcall-used* flags
      sparc/build: Add SPARC target flags for compiling with clang

 arch/sparc/Makefile      | 4 ++--
 arch/sparc/vdso/Makefile | 2 +-
 scripts/Makefile.clang   | 1 +
 3 files changed, 4 insertions(+), 3 deletions(-)
---
base-commit: 4d145e3f830ba2c2745b42bfba5c2f8fcb8d078a
change-id: 20240620-sparc-cflags-e7f2dbbd4b9d

Best regards,
-- 
Koakuma <koachan@protonmail.com>

[PATCH v2 1/2] sparc/build: Remove all usage of -fcall-used* flags

[Koakuma via B4 Relay]

From: Koakuma <koachan@protonmail.com>

Remove all usage of -fcall-used* flags so that all flags used are
portable between GCC and clang.

The reasoning is as follows:

In the (normal) 32-bit ABI, %g5 and %g7 is normally reserved, and in
the 64-bit ABI, %g7 is the reserved one.
Linux turns them into volatile registers by the way of -fcall-used-*,
but on the other hand, omitting the flags shouldn't be harmful;
compilers will now simply refuse to touch them, and any assembly
code that happens to touch them would still work like usual (because
Linux' conventions already treats them as volatile anyway).

Signed-off-by: Koakuma <koachan@protonmail.com>
---
 arch/sparc/Makefile      | 4 ++--
 arch/sparc/vdso/Makefile | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
index 757451c3ea1d..7318a8b452c3 100644
--- a/arch/sparc/Makefile
+++ b/arch/sparc/Makefile
@@ -29,7 +29,7 @@ UTS_MACHINE    := sparc
 # versions of gcc.  Some gcc versions won't pass -Av8 to binutils when you
 # give -mcpu=v8.  This silently worked with older bintutils versions but
 # does not any more.
-KBUILD_CFLAGS  += -m32 -mcpu=v8 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
+KBUILD_CFLAGS  += -m32 -mcpu=v8 -pipe -mno-fpu
 KBUILD_CFLAGS  += -Wa,-Av8
 
 KBUILD_AFLAGS  += -m32 -Wa,-Av8
@@ -45,7 +45,7 @@ export BITS   := 64
 UTS_MACHINE   := sparc64
 
 KBUILD_CFLAGS += -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow
-KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare
+KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -Wno-sign-compare
 KBUILD_CFLAGS += -Wa,--undeclared-regs
 KBUILD_CFLAGS += $(call cc-option,-mtune=ultrasparc3)
 KBUILD_AFLAGS += -m64 -mcpu=ultrasparc -Wa,--undeclared-regs
diff --git a/arch/sparc/vdso/Makefile b/arch/sparc/vdso/Makefile
index 243dbfc4609d..e009443145af 100644
--- a/arch/sparc/vdso/Makefile
+++ b/arch/sparc/vdso/Makefile
@@ -46,7 +46,7 @@ CFL := $(PROFILING) -mcmodel=medlow -fPIC -O2 -fasynchronous-unwind-tables -m64
        -fno-omit-frame-pointer -foptimize-sibling-calls \
        -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
 
-SPARC_REG_CFLAGS = -ffixed-g4 -ffixed-g5 -fcall-used-g5 -fcall-used-g7
+SPARC_REG_CFLAGS = -ffixed-g4 -ffixed-g5
 
 $(vobjs): KBUILD_CFLAGS := $(filter-out $(RANDSTRUCT_CFLAGS) $(GCC_PLUGINS_CFLAGS) $(SPARC_REG_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
 

-- 
2.45.2

Re: [PATCH v2 1/2] sparc/build: Remove all usage of -fcall-used* flags

[Nathan Chancellor]

On Wed, Jul 17, 2024 at 11:10:15PM +0700, Koakuma wrote:
> Remove all usage of -fcall-used* flags so that all flags used are
> portable between GCC and clang.
> 
> The reasoning is as follows:
> 
> In the (normal) 32-bit ABI, %g5 and %g7 is normally reserved, and in
> the 64-bit ABI, %g7 is the reserved one.
> Linux turns them into volatile registers by the way of -fcall-used-*,
> but on the other hand, omitting the flags shouldn't be harmful;
> compilers will now simply refuse to touch them, and any assembly
> code that happens to touch them would still work like usual (because
> Linux' conventions already treats them as volatile anyway).
> 
> Signed-off-by: Koakuma <koachan@protonmail.com>

As before, I tested this series with the vDSO patch mentioned before and
a version of LLVM that supports the -m{,no-}v8plus flags and I was able
to successfully boot a kernel in QEMU :)

Tested-by: Nathan Chancellor <nathan@kernel.org>

> ---
>  arch/sparc/Makefile      | 4 ++--
>  arch/sparc/vdso/Makefile | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
> index 757451c3ea1d..7318a8b452c3 100644
> --- a/arch/sparc/Makefile
> +++ b/arch/sparc/Makefile
> @@ -29,7 +29,7 @@ UTS_MACHINE    := sparc
>  # versions of gcc.  Some gcc versions won't pass -Av8 to binutils when you
>  # give -mcpu=v8.  This silently worked with older bintutils versions but
>  # does not any more.
> -KBUILD_CFLAGS  += -m32 -mcpu=v8 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
> +KBUILD_CFLAGS  += -m32 -mcpu=v8 -pipe -mno-fpu
>  KBUILD_CFLAGS  += -Wa,-Av8
>  
>  KBUILD_AFLAGS  += -m32 -Wa,-Av8
> @@ -45,7 +45,7 @@ export BITS   := 64
>  UTS_MACHINE   := sparc64
>  
>  KBUILD_CFLAGS += -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow
> -KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare
> +KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -Wno-sign-compare
>  KBUILD_CFLAGS += -Wa,--undeclared-regs
>  KBUILD_CFLAGS += $(call cc-option,-mtune=ultrasparc3)
>  KBUILD_AFLAGS += -m64 -mcpu=ultrasparc -Wa,--undeclared-regs
> diff --git a/arch/sparc/vdso/Makefile b/arch/sparc/vdso/Makefile
> index 243dbfc4609d..e009443145af 100644
> --- a/arch/sparc/vdso/Makefile
> +++ b/arch/sparc/vdso/Makefile
> @@ -46,7 +46,7 @@ CFL := $(PROFILING) -mcmodel=medlow -fPIC -O2 -fasynchronous-unwind-tables -m64
>         -fno-omit-frame-pointer -foptimize-sibling-calls \
>         -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
>  
> -SPARC_REG_CFLAGS = -ffixed-g4 -ffixed-g5 -fcall-used-g5 -fcall-used-g7
> +SPARC_REG_CFLAGS = -ffixed-g4 -ffixed-g5
>  
>  $(vobjs): KBUILD_CFLAGS := $(filter-out $(RANDSTRUCT_CFLAGS) $(GCC_PLUGINS_CFLAGS) $(SPARC_REG_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
>  
> 
> -- 
> 2.45.2
> 

Re: [PATCH v2 1/2] sparc/build: Remove all usage of -fcall-used* flags

[Andreas Larsson]

Hi,

Sorry for being silent on your two patch sets. I did not have time to
look into them for 6.12.

On 2024-07-17 18:10, Koakuma via B4 Relay wrote:
> From: Koakuma <koachan@protonmail.com>
> 
> Remove all usage of -fcall-used* flags so that all flags used are
> portable between GCC and clang.
> 
> The reasoning is as follows:
> 
> In the (normal) 32-bit ABI, %g5 and %g7 is normally reserved, and in
> the 64-bit ABI, %g7 is the reserved one.
> Linux turns them into volatile registers by the way of -fcall-used-*,
> but on the other hand, omitting the flags shouldn't be harmful;
> compilers will now simply refuse to touch them, and any assembly
> code that happens to touch them would still work like usual (because
> Linux' conventions already treats them as volatile anyway).
> 
> Signed-off-by: Koakuma <koachan@protonmail.com>
> ---
>  arch/sparc/Makefile      | 4 ++--
>  arch/sparc/vdso/Makefile | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
> index 757451c3ea1d..7318a8b452c3 100644
> --- a/arch/sparc/Makefile
> +++ b/arch/sparc/Makefile
> @@ -29,7 +29,7 @@ UTS_MACHINE    := sparc
>  # versions of gcc.  Some gcc versions won't pass -Av8 to binutils when you
>  # give -mcpu=v8.  This silently worked with older bintutils versions but
>  # does not any more.
> -KBUILD_CFLAGS  += -m32 -mcpu=v8 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
> +KBUILD_CFLAGS  += -m32 -mcpu=v8 -pipe -mno-fpu

Couldn't you use ifndef CONFIG_CC_IS_CLANG or perhaps better, use 
$(call cc-option,-fcall-used-g5) and $(call cc-option,-fcall-used-g7) to
not remove the possibility for gcc to make use of these registers?

>  KBUILD_CFLAGS  += -Wa,-Av8
>  
>  KBUILD_AFLAGS  += -m32 -Wa,-Av8
> @@ -45,7 +45,7 @@ export BITS   := 64
>  UTS_MACHINE   := sparc64
>  
>  KBUILD_CFLAGS += -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow
> -KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare
> +KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -Wno-sign-compare

Similarly here

>  KBUILD_CFLAGS += -Wa,--undeclared-regs
>  KBUILD_CFLAGS += $(call cc-option,-mtune=ultrasparc3)
>  KBUILD_AFLAGS += -m64 -mcpu=ultrasparc -Wa,--undeclared-regs
> diff --git a/arch/sparc/vdso/Makefile b/arch/sparc/vdso/Makefile
> index 243dbfc4609d..e009443145af 100644
> --- a/arch/sparc/vdso/Makefile
> +++ b/arch/sparc/vdso/Makefile
> @@ -46,7 +46,7 @@ CFL := $(PROFILING) -mcmodel=medlow -fPIC -O2 -fasynchronous-unwind-tables -m64
>         -fno-omit-frame-pointer -foptimize-sibling-calls \
>         -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
>  
> -SPARC_REG_CFLAGS = -ffixed-g4 -ffixed-g5 -fcall-used-g5 -fcall-used-g7
> +SPARC_REG_CFLAGS = -ffixed-g4 -ffixed-g5

and here.

>  
>  $(vobjs): KBUILD_CFLAGS := $(filter-out $(RANDSTRUCT_CFLAGS) $(GCC_PLUGINS_CFLAGS) $(SPARC_REG_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
>  
> 

Thanks,
Andreas

Re: [PATCH v2 1/2] sparc/build: Remove all usage of -fcall-used* flags

[Koakuma]

Andreas Larsson <andreas@gaisler.com> wrote:
> Couldn't you use ifndef CONFIG_CC_IS_CLANG or perhaps better, use
> $(call cc-option,-fcall-used-g5) and $(call cc-option,-fcall-used-g7) to
> not remove the possibility for gcc to make use of these registers?

Sure sure! It works okay that way too.
But before I send a v3, let me wait for clarification for the docs issue
for the other patch.

[PATCH v2 2/2] sparc/build: Add SPARC target flags for compiling with clang

[Koakuma via B4 Relay]

From: Koakuma <koachan@protonmail.com>

clang only supports building 64-bit kernel, so we use the
sparc64-linux-gnu target.

See also: https://lore.kernel.org/lkml/e26PTXUXEz8OYXmaeKn4Mpuejr4IOlFfFwdB5vpsluXlYiqDdlyQTYcDtdAny_o4gO4SfPeQCCN2qpyT6e0nog5EaP3xk2SeUPTrF54p1gM=@protonmail.com/T/#m068e010dcf8b99d3510a90d7532bcdb70e2e2c6b

Signed-off-by: Koakuma <koachan@protonmail.com>
---
 scripts/Makefile.clang | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/Makefile.clang b/scripts/Makefile.clang
index 6c23c6af797f..2435efae67f5 100644
--- a/scripts/Makefile.clang
+++ b/scripts/Makefile.clang
@@ -10,6 +10,7 @@ CLANG_TARGET_FLAGS_mips		:= mipsel-linux-gnu
 CLANG_TARGET_FLAGS_powerpc	:= powerpc64le-linux-gnu
 CLANG_TARGET_FLAGS_riscv	:= riscv64-linux-gnu
 CLANG_TARGET_FLAGS_s390		:= s390x-linux-gnu
+CLANG_TARGET_FLAGS_sparc	:= sparc64-linux-gnu
 CLANG_TARGET_FLAGS_x86		:= x86_64-linux-gnu
 CLANG_TARGET_FLAGS_um		:= $(CLANG_TARGET_FLAGS_$(SUBARCH))
 CLANG_TARGET_FLAGS		:= $(CLANG_TARGET_FLAGS_$(SRCARCH))

-- 
2.45.2

Re: [PATCH v2 2/2] sparc/build: Add SPARC target flags for compiling with clang

[Nathan Chancellor]

Hi Koakuma,

On Wed, Jul 17, 2024 at 11:10:16PM +0700, Koakuma wrote:
> clang only supports building 64-bit kernel, so we use the
> sparc64-linux-gnu target.

It should not really matter which sparc target you pick (32-bit or
64-bit), as the comment at the top of the file mentions that
architectures should use the command line options to control word size
and endianness, which arch/sparc does. Not that I really think it is
worth correcting, just thought I would mention :)

> See also: https://lore.kernel.org/lkml/e26PTXUXEz8OYXmaeKn4Mpuejr4IOlFfFwdB5vpsluXlYiqDdlyQTYcDtdAny_o4gO4SfPeQCCN2qpyT6e0nog5EaP3xk2SeUPTrF54p1gM=@protonmail.com/T/#m068e010dcf8b99d3510a90d7532bcdb70e2e2c6b
> 
> Signed-off-by: Koakuma <koachan@protonmail.com>

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

Thanks for all the work you have done driving this, it is pretty cool to
see :)

> ---
>  scripts/Makefile.clang | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/scripts/Makefile.clang b/scripts/Makefile.clang
> index 6c23c6af797f..2435efae67f5 100644
> --- a/scripts/Makefile.clang
> +++ b/scripts/Makefile.clang
> @@ -10,6 +10,7 @@ CLANG_TARGET_FLAGS_mips		:= mipsel-linux-gnu
>  CLANG_TARGET_FLAGS_powerpc	:= powerpc64le-linux-gnu
>  CLANG_TARGET_FLAGS_riscv	:= riscv64-linux-gnu
>  CLANG_TARGET_FLAGS_s390		:= s390x-linux-gnu
> +CLANG_TARGET_FLAGS_sparc	:= sparc64-linux-gnu
>  CLANG_TARGET_FLAGS_x86		:= x86_64-linux-gnu
>  CLANG_TARGET_FLAGS_um		:= $(CLANG_TARGET_FLAGS_$(SUBARCH))
>  CLANG_TARGET_FLAGS		:= $(CLANG_TARGET_FLAGS_$(SRCARCH))
> 
> -- 
> 2.45.2
> 

Re: [PATCH v2 2/2] sparc/build: Add SPARC target flags for compiling with clang

[Masahiro Yamada]

On Thu, Jul 18, 2024 at 1:12 AM Koakuma via B4 Relay
<devnull+koachan.protonmail.com@kernel.org> wrote:
>
> From: Koakuma <koachan@protonmail.com>
>
> clang only supports building 64-bit kernel, so we use the
> sparc64-linux-gnu target.
>
> See also: https://lore.kernel.org/lkml/e26PTXUXEz8OYXmaeKn4Mpuejr4IOlFfFwdB5vpsluXlYiqDdlyQTYcDtdAny_o4gO4SfPeQCCN2qpyT6e0nog5EaP3xk2SeUPTrF54p1gM=@protonmail.com/T/#m068e010dcf8b99d3510a90d7532bcdb70e2e2c6b
>
> Signed-off-by: Koakuma <koachan@protonmail.com>



Acked-by: Masahiro Yamada <masahiroy@kernel.org>


(I assume this will go through the sparc subsystem)




-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Nathan Chancellor]

Hi Andreas,

On Wed, Jul 17, 2024 at 11:10:14PM +0700, Koakuma wrote:
> This changes the CFLAGS for building the SPARC kernel so that it can be
> built with clang, as a follow up from the discussion in this thread:
> 
> https://lore.kernel.org/lkml/JAYB7uS-EdLABTR4iWZdtFOVa5MvlKosIrD_cKTzgeozCOGRM7lhxeLigFB1g3exX445I_W5VKB-tAzl2_G1zCVJRQjp67ODfsSqiZWOZ9o=@protonmail.com/T/#u
...
> Building with these changes still result in a working kernel,
> at least for Sun T5120, Oracle T4-1, and qemu virtual machines.
> 
> On the LLVM side, the effort for building Linux/SPARC is tracked here:
> https://github.com/llvm/llvm-project/issues/40792
> 
> Signed-off-by: Koakuma <koachan@protonmail.com>
> ---
> Changes in v2:
> - Remove the -mv8plus change; it will be handled on clang side:
>   https://github.com/llvm/llvm-project/pull/98713
> - Add CLANG_TARGET_FLAGS as suggested in v1 review.
> - Link to v1: https://lore.kernel.org/r/20240620-sparc-cflags-v1-1-bba7d0ff7d42@protonmail.com
> 
> ---
> Koakuma (2):
>       sparc/build: Remove all usage of -fcall-used* flags
>       sparc/build: Add SPARC target flags for compiling with clang
> 
>  arch/sparc/Makefile      | 4 ++--
>  arch/sparc/vdso/Makefile | 2 +-
>  scripts/Makefile.clang   | 1 +
>  3 files changed, 4 insertions(+), 3 deletions(-)

Would you be able to help move this series [1] and its companion patch
for the vDSO [2] along to Linus for 6.13? If you are not able to for
whatever reason but the changes look reasonable to you, would you be
able to provide an Ack so it can be chauffeured by someone else, such as
Masahiro/Kbuild or Andrew/-mm?

For the record, I retested these three changes on top of 6.12-rc4, where
they still apply cleanly. Now that the LLVM PR linked above (98713) has
been merged into LLVM main, a clang built straight from llvm-project.git
can build the kernel with this series (I tested at dca43a1c82f1).

[1]: https://lore.kernel.org/all/20240717-sparc-cflags-v2-0-259407e6eb5f@protonmail.com/
[2]: https://lore.kernel.org/all/20240808-sparc-shr64-v2-1-fd18f1b2cea9@protonmail.com/

Cheers,
Nathan

Re: [PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Masahiro Yamada]

On Tue, Oct 22, 2024 at 5:17 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Hi Andreas,
>
> On Wed, Jul 17, 2024 at 11:10:14PM +0700, Koakuma wrote:
> > This changes the CFLAGS for building the SPARC kernel so that it can be
> > built with clang, as a follow up from the discussion in this thread:
> >
> > https://lore.kernel.org/lkml/JAYB7uS-EdLABTR4iWZdtFOVa5MvlKosIrD_cKTzgeozCOGRM7lhxeLigFB1g3exX445I_W5VKB-tAzl2_G1zCVJRQjp67ODfsSqiZWOZ9o=@protonmail.com/T/#u
> ...
> > Building with these changes still result in a working kernel,
> > at least for Sun T5120, Oracle T4-1, and qemu virtual machines.
> >
> > On the LLVM side, the effort for building Linux/SPARC is tracked here:
> > https://github.com/llvm/llvm-project/issues/40792
> >
> > Signed-off-by: Koakuma <koachan@protonmail.com>
> > ---
> > Changes in v2:
> > - Remove the -mv8plus change; it will be handled on clang side:
> >   https://github.com/llvm/llvm-project/pull/98713
> > - Add CLANG_TARGET_FLAGS as suggested in v1 review.
> > - Link to v1: https://lore.kernel.org/r/20240620-sparc-cflags-v1-1-bba7d0ff7d42@protonmail.com
> >
> > ---
> > Koakuma (2):
> >       sparc/build: Remove all usage of -fcall-used* flags
> >       sparc/build: Add SPARC target flags for compiling with clang
> >
> >  arch/sparc/Makefile      | 4 ++--
> >  arch/sparc/vdso/Makefile | 2 +-
> >  scripts/Makefile.clang   | 1 +
> >  3 files changed, 4 insertions(+), 3 deletions(-)
>
> Would you be able to help move this series [1] and its companion patch
> for the vDSO [2] along to Linus for 6.13? If you are not able to for
> whatever reason but the changes look reasonable to you, would you be
> able to provide an Ack so it can be chauffeured by someone else, such as
> Masahiro/Kbuild or Andrew/-mm?
>
> For the record, I retested these three changes on top of 6.12-rc4, where
> they still apply cleanly. Now that the LLVM PR linked above (98713) has
> been merged into LLVM main, a clang built straight from llvm-project.git
> can build the kernel with this series (I tested at dca43a1c82f1).
>
> [1]: https://lore.kernel.org/all/20240717-sparc-cflags-v2-0-259407e6eb5f@protonmail.com/
> [2]: https://lore.kernel.org/all/20240808-sparc-shr64-v2-1-fd18f1b2cea9@protonmail.com/
>
> Cheers,
> Nathan



I applied this patch set, but I still observe a build error.


masahiro@zoe:~/workspace/linux-kbuild(kbuild)$
~/tools/llvm-latest/bin/clang --version
ClangBuiltLinux clang version 20.0.0git
(https://github.com/llvm/llvm-project.git
d1401822e2d2753bed3ac597a42cc0b261de40a4)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /home/masahiro/tools/llvm-latest/bin
masahiro@zoe:~/workspace/linux-kbuild(kbuild)$ make
LLVM=~/tools/llvm-latest/bin/  ARCH=sparc sparc64_defconfig all
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/menu.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
  SYNC    include/config/auto.conf.cmd
  HOSTCC  scripts/genksyms/genksyms.o
  HOSTCC  scripts/genksyms/parse.tab.o
  HOSTCC  scripts/genksyms/lex.lex.o
  HOSTLD  scripts/genksyms/genksyms
  HOSTCC  scripts/kallsyms
  UPD     include/generated/compile.h
  CC      scripts/mod/empty.o
clang: error: unsupported argument '--undeclared-regs' to option '-Wa,'
make[3]: *** [scripts/Makefile.build:229: scripts/mod/empty.o] Error 1
make[2]: *** [Makefile:1208: prepare0] Error 2
make[1]: *** [/home/masahiro/workspace/linux-kbuild/Makefile:347:
__build_one_by_one] Error 2
make: *** [Makefile:224: __sub-make] Error 2



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Nathan Chancellor]

On Wed, Oct 23, 2024 at 04:10:01AM +0900, Masahiro Yamada wrote:
> I applied this patch set, but I still observe a build error.
...
> masahiro@zoe:~/workspace/linux-kbuild(kbuild)$ make
> LLVM=~/tools/llvm-latest/bin/  ARCH=sparc sparc64_defconfig all
...
> clang: error: unsupported argument '--undeclared-regs' to option '-Wa,'

Koakuma might know more than I do but I did not test either the
integrated assembler or the rest of the LLVM tools; I only tested clang
for CC. As far as I am aware, that has been where most of the effort in
llvm-project has been going and I think there are probably other fixes
that will be needed for the other tools. The command I tested was:

  $ make -skj"$(nproc)" \
         ARCH=sparc64 \
         CC=clang \
         CROSS_COMPILE=sparc64-linux-gnu- \
         LLVM_IAS=0 \
         mrproper defconfig all

I see this as more of a stepping stone series to make testing those
other components easier as time goes on, hence why I did not really
consider user facing documentation either like you brought up in the
other thread.

Cheers,
Nathan

Re: [PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Koakuma]

Nathan Chancellor <nathan@kernel.org> wrote: 
> Koakuma might know more than I do but I did not test either the
> integrated assembler or the rest of the LLVM tools; I only tested clang
> for CC. As far as I am aware, that has been where most of the effort in
> llvm-project has been going and I think there are probably other fixes
> that will be needed for the other tools. The command I tested was:
> 
> $ make -skj"$(nproc)" \
> ARCH=sparc64 \
> CC=clang \
> CROSS_COMPILE=sparc64-linux-gnu- \
> LLVM_IAS=0 \
> mrproper defconfig all
> 
> I see this as more of a stepping stone series to make testing those
> other components easier as time goes on, hence why I did not really
> consider user facing documentation either like you brought up in the
> other thread.
> 
> Cheers,
> Nathan

Ah, pardon me for forgetting to say it in the cover letter.
But yeah. At the moment only clang as CC works, all other LLVM tools are still
incomplete and need some work to be able to build the kernel, so these patches
indeed are intended as stepping stones to make it easier to work on
the rest of the tools.

I'm not sure if I should update the documentation now given that LLVM support
is nowhere near as complete as other architectures, but I'll do it if needed...

Re: [PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Masahiro Yamada]

On Wed, Oct 23, 2024 at 9:44 AM Koakuma <koachan@protonmail.com> wrote:
>
> Nathan Chancellor <nathan@kernel.org> wrote:
> > Koakuma might know more than I do but I did not test either the
> > integrated assembler or the rest of the LLVM tools; I only tested clang
> > for CC. As far as I am aware, that has been where most of the effort in
> > llvm-project has been going and I think there are probably other fixes
> > that will be needed for the other tools. The command I tested was:
> >
> > $ make -skj"$(nproc)" \
> > ARCH=sparc64 \
> > CC=clang \
> > CROSS_COMPILE=sparc64-linux-gnu- \
> > LLVM_IAS=0 \
> > mrproper defconfig all
> >
> > I see this as more of a stepping stone series to make testing those
> > other components easier as time goes on, hence why I did not really
> > consider user facing documentation either like you brought up in the
> > other thread.
> >
> > Cheers,
> > Nathan
>
> Ah, pardon me for forgetting to say it in the cover letter.
> But yeah. At the moment only clang as CC works, all other LLVM tools are still
> incomplete and need some work to be able to build the kernel, so these patches
> indeed are intended as stepping stones to make it easier to work on
> the rest of the tools.
>
> I'm not sure if I should update the documentation now given that LLVM support
> is nowhere near as complete as other architectures, but I'll do it if needed...

Nathan said he was able to build the kernel.


If so, I think this should be documented (required LLVM version and
the supported build command),
otherwise people cannot test this patch.




Anyway, the sparc subsystem is maintained.
I hope Andreas can take a look.



commit eb5b0f9812fff72f82e6ecc9ad4dafaf4971a16a
Merge: 4ffc45808373 d21dffe51baa
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Sep 25 11:21:06 2024 -0700

    Merge tag 'sparc-for-6.12-tag1' of
git://git.kernel.org/pub/scm/linux/kernel/git/alarsson/linux-sparc

    Pull sparc32 update from Andreas Larsson:

     - Remove an unused variable for sparc32

    * tag 'sparc-for-6.12-tag1' of
git://git.kernel.org/pub/scm/linux/kernel/git/alarsson/linux-sparc:
      arch/sparc: remove unused varible paddrbase in function leon_swprobe()

commit 7dd894c1bf65a9591ba27f6175cf3238748deb47
Merge: 1c7d0c3af5cc a3da15389112
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jul 18 15:48:41 2024 -0700

    Merge tag 'sparc-for-6.11-tag1' of
git://git.kernel.org/pub/scm/linux/kernel/git/alarsson/linux-sparc

    Pull sparc updates from Andreas Larsson:

     - Add MODULE_DESCRIPTION for a number of sbus drivers

     - Fix linking error for large sparc32 kernels

     - Fix incorrect functions signature and prototype warnings for sparc64

    * tag 'sparc-for-6.11-tag1' of
git://git.kernel.org/pub/scm/linux/kernel/git/alarsson/linux-sparc:
      sparc64: Fix prototype warnings in hibernate.c
      sparc64: Fix prototype warning for prom_get_mmu_ihandle
      sparc64: Fix incorrect function signature and add prototype for
prom_cif_init
      sparc64: Fix prototype warnings for floppy_64.h
      sparc32: Fix truncated relocation errors when linking large kernels
      sbus: add missing MODULE_DESCRIPTION() macros


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Nathan Chancellor]

On Wed, Oct 23, 2024 at 12:38:59PM +0900, Masahiro Yamada wrote:
> On Wed, Oct 23, 2024 at 9:44 AM Koakuma <koachan@protonmail.com> wrote:
> > I'm not sure if I should update the documentation now given that LLVM support
> > is nowhere near as complete as other architectures, but I'll do it if needed...
> 
> Nathan said he was able to build the kernel.
> 
> If so, I think this should be documented (required LLVM version and
> the supported build command),
> otherwise people cannot test this patch.

I am not sure that there is a super concise way to describe for
Documentation/kbuild/llvm.rst that sparc currently requires 'CC=clang
LLVM_IAS=0' along with a build of clang from the main branch of
llvm-project to work properly. I worry that adding any sort of mention
of sparc in there will have people flooding to try older versions of
clang like you did or LLVM=1 when there are obviously known issues that
the upstream LLVM folks have not had a chance to tackle (but maybe it
will be good to get issues on file for those).

If it would be useful, I could send a separate email documenting exactly
what was tested and how it was tested as a reference in the face of
future changes, until better support for the LLVM tools is enacted.

Cheers,
Nathan

Re: [PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Koakuma]

Masahiro Yamada <masahiroy@kernel.org> wrote:
> I think this should be documented (required LLVM version and
> the supported build command),
> otherwise people cannot test this patch.

Nathan Chancellor <nathan@kernel.org> wrote:
> I am not sure that there is a super concise way to describe for
> Documentation/kbuild/llvm.rst that sparc currently requires 'CC=clang
> LLVM_IAS=0' along with a build of clang from the main branch of
> llvm-project to work properly.

So about this, as a middle ground, would it be okay if I put

``CC=clang LLVM_IAS=0`` (LLVM >= 20)

In the documentation, in a similar manner to the s390x entry?
I know that LLVM 20 is still a couple months away but those commits will
likely be released with that version, and since it also tells people
to not use a version that is too old, I think it should be okay (?)

Re: [PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Masahiro Yamada]

On Sat, Oct 26, 2024 at 4:53 PM Koakuma <koachan@protonmail.com> wrote:
>
> Masahiro Yamada <masahiroy@kernel.org> wrote:
> > I think this should be documented (required LLVM version and
> > the supported build command),
> > otherwise people cannot test this patch.
>
> Nathan Chancellor <nathan@kernel.org> wrote:
> > I am not sure that there is a super concise way to describe for
> > Documentation/kbuild/llvm.rst that sparc currently requires 'CC=clang
> > LLVM_IAS=0' along with a build of clang from the main branch of
> > llvm-project to work properly.
>
> So about this, as a middle ground, would it be okay if I put
>
> ``CC=clang LLVM_IAS=0`` (LLVM >= 20)

I am OK with this.

Having this info is more helpful than nothing.



> In the documentation, in a similar manner to the s390x entry?
> I know that LLVM 20 is still a couple months away but those commits will
> likely be released with that version, and since it also tells people
> to not use a version that is too old, I think it should be okay (?)
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Nathan Chancellor]

On Sat, Oct 26, 2024 at 02:52:52PM +0000, Koakuma wrote:
> Masahiro Yamada <masahiroy@kernel.org> wrote:
> > I think this should be documented (required LLVM version and
> > the supported build command),
> > otherwise people cannot test this patch.
> 
> Nathan Chancellor <nathan@kernel.org> wrote:
> > I am not sure that there is a super concise way to describe for
> > Documentation/kbuild/llvm.rst that sparc currently requires 'CC=clang
> > LLVM_IAS=0' along with a build of clang from the main branch of
> > llvm-project to work properly.
> 
> So about this, as a middle ground, would it be okay if I put
> 
> ``CC=clang LLVM_IAS=0`` (LLVM >= 20)
> 
> In the documentation, in a similar manner to the s390x entry?
> I know that LLVM 20 is still a couple months away but those commits will
> likely be released with that version, and since it also tells people
> to not use a version that is too old, I think it should be okay (?)

Yes, I think that would be reasonable.

Cheers,
Nathan

Re: [PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Masahiro Yamada]

On Wed, Oct 23, 2024 at 5:07 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Wed, Oct 23, 2024 at 04:10:01AM +0900, Masahiro Yamada wrote:
> > I applied this patch set, but I still observe a build error.
> ...
> > masahiro@zoe:~/workspace/linux-kbuild(kbuild)$ make
> > LLVM=~/tools/llvm-latest/bin/  ARCH=sparc sparc64_defconfig all
> ...
> > clang: error: unsupported argument '--undeclared-regs' to option '-Wa,'
>
> Koakuma might know more than I do but I did not test either the
> integrated assembler or the rest of the LLVM tools; I only tested clang
> for CC. As far as I am aware, that has been where most of the effort in
> llvm-project has been going and I think there are probably other fixes
> that will be needed for the other tools. The command I tested was:
>
>   $ make -skj"$(nproc)" \
>          ARCH=sparc64 \
>          CC=clang \
>          CROSS_COMPILE=sparc64-linux-gnu- \
>          LLVM_IAS=0 \
>          mrproper defconfig all


With running this command in Ubuntu 24.10, I got improvements,
but I still got another build error.  (unknown argument: '-mv8plus')


masahiro@3606c94ac88c:~/workspace/linux-kbuild$ make -skj"$(nproc)"
ARCH=sparc64 CC=clang CROSS_COMPILE=sparc64-linux-gnu- LLVM_IAS=0
mrproper defconfig all
<stdin>:1519:2: warning: syscall clone3 not implemented [-W#warnings]
 1519 | #warning syscall clone3 not implemented
      |  ^
1 warning generated.
arch/sparc/vdso/vclock_gettime.c:274:1: warning: no previous prototype
for function '__vdso_clock_gettime' [-Wmissing-prototypes]
  274 | __vdso_clock_gettime(clockid_t clock, struct __kernel_old_timespec *ts)
      | ^
arch/sparc/vdso/vclock_gettime.c:273:9: note: declare 'static' if the
function is not intended to be used outside of this translation unit
  273 | notrace int
      |         ^
      |         static
arch/sparc/vdso/vclock_gettime.c:302:1: warning: no previous prototype
for function '__vdso_clock_gettime_stick' [-Wmissing-prototypes]
  302 | __vdso_clock_gettime_stick(clockid_t clock, struct
__kernel_old_timespec *ts)
      | ^
arch/sparc/vdso/vclock_gettime.c:301:9: note: declare 'static' if the
function is not intended to be used outside of this translation unit
  301 | notrace int
      |         ^
      |         static
arch/sparc/vdso/vclock_gettime.c:327:1: warning: no previous prototype
for function '__vdso_gettimeofday' [-Wmissing-prototypes]
  327 | __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct
timezone *tz)
      | ^
arch/sparc/vdso/vclock_gettime.c:326:9: note: declare 'static' if the
function is not intended to be used outside of this translation unit
  326 | notrace int
      |         ^
      |         static
arch/sparc/vdso/vclock_gettime.c:363:1: warning: no previous prototype
for function '__vdso_gettimeofday_stick' [-Wmissing-prototypes]
  363 | __vdso_gettimeofday_stick(struct __kernel_old_timeval *tv,
struct timezone *tz)
      | ^
arch/sparc/vdso/vclock_gettime.c:362:9: note: declare 'static' if the
function is not intended to be used outside of this translation unit
  362 | notrace int
      |         ^
      |         static
4 warnings generated.
clang: error: unknown argument: '-mv8plus'
make[5]: *** [scripts/Makefile.build:229:
arch/sparc/vdso/vdso32/vclock_gettime.o] Error 1
sparc64-linux-gnu-ld: warning: arch/sparc/vdso/vdso-note.o: missing
.note.GNU-stack section implies executable stack
sparc64-linux-gnu-ld: NOTE: This behaviour is deprecated and will be
removed in a future version of the linker
make[5]: Target 'arch/sparc/vdso/' not remade because of errors.
make[4]: *** [scripts/Makefile.build:478: arch/sparc/vdso] Error 2



masahiro@3606c94ac88c:~/workspace/linux-kbuild$ clang --version
Ubuntu clang version 19.1.1 (1ubuntu1)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-19/bin


Is this version too old, or am I missing something?





> I see this as more of a stepping stone series to make testing those
> other components easier as time goes on, hence why I did not really
> consider user facing documentation either like you brought up in the
> other thread.
>
> Cheers,
> Nathan




-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Nathan Chancellor]

On Wed, Oct 23, 2024 at 12:29:26PM +0900, Masahiro Yamada wrote:
> With running this command in Ubuntu 24.10, I got improvements,
> but I still got another build error.  (unknown argument: '-mv8plus')

> clang: error: unknown argument: '-mv8plus'
> make[5]: *** [scripts/Makefile.build:229:

> masahiro@3606c94ac88c:~/workspace/linux-kbuild$ clang --version
> Ubuntu clang version 19.1.1 (1ubuntu1)

> Is this version too old, or am I missing something?

Yes, that is the issue resolved by the pull request that Koakuma
mentioned in the changelog:

https://github.com/llvm/llvm-project/pull/98713
https://github.com/llvm/llvm-project/commit/6c270a8b9f1e1b80a6016aafb438db7dd89bcb99

which depends on some codegen changes too:

https://github.com/llvm/llvm-project/commit/aca971d336d9c7650120fc0fd6dfe58866408216

Those patches missed the LLVM 19 branch point by a couple of weeks:

https://github.com/llvm/llvm-project/commit/8f701b5df0adb3a2960d78ca2ad9cf53f39ba2fe

They are relatively simple, so maybe we would have a chance of
convincing the stable maintainer of LLVM to take them for a later 19.1
release but given how little usage this is likely to see until the full
LLVM stack is further developed, I am not sure that petition would be
worth it.

Cheers,
Nathan

Re: [PATCH v2 0/2] sparc/build: Rework CFLAGS for clang compatibility

[Masahiro Yamada]

On Tue, Oct 22, 2024 at 5:17 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Hi Andreas,
>
> On Wed, Jul 17, 2024 at 11:10:14PM +0700, Koakuma wrote:
> > This changes the CFLAGS for building the SPARC kernel so that it can be
> > built with clang, as a follow up from the discussion in this thread:
> >
> > https://lore.kernel.org/lkml/JAYB7uS-EdLABTR4iWZdtFOVa5MvlKosIrD_cKTzgeozCOGRM7lhxeLigFB1g3exX445I_W5VKB-tAzl2_G1zCVJRQjp67ODfsSqiZWOZ9o=@protonmail.com/T/#u
> ...
> > Building with these changes still result in a working kernel,
> > at least for Sun T5120, Oracle T4-1, and qemu virtual machines.
> >
> > On the LLVM side, the effort for building Linux/SPARC is tracked here:
> > https://github.com/llvm/llvm-project/issues/40792
> >
> > Signed-off-by: Koakuma <koachan@protonmail.com>
> > ---
> > Changes in v2:
> > - Remove the -mv8plus change; it will be handled on clang side:
> >   https://github.com/llvm/llvm-project/pull/98713
> > - Add CLANG_TARGET_FLAGS as suggested in v1 review.
> > - Link to v1: https://lore.kernel.org/r/20240620-sparc-cflags-v1-1-bba7d0ff7d42@protonmail.com
> >
> > ---
> > Koakuma (2):
> >       sparc/build: Remove all usage of -fcall-used* flags
> >       sparc/build: Add SPARC target flags for compiling with clang
> >
> >  arch/sparc/Makefile      | 4 ++--
> >  arch/sparc/vdso/Makefile | 2 +-
> >  scripts/Makefile.clang   | 1 +
> >  3 files changed, 4 insertions(+), 3 deletions(-)
>
> Would you be able to help move this series [1] and its companion patch
> for the vDSO [2] along to Linus for 6.13? If you are not able to for
> whatever reason but the changes look reasonable to you, would you be
> able to provide an Ack so it can be chauffeured by someone else, such as
> Masahiro/Kbuild or Andrew/-mm?
>
> For the record, I retested these three changes on top of 6.12-rc4, where
> they still apply cleanly. Now that the LLVM PR linked above (98713) has
> been merged into LLVM main, a clang built straight from llvm-project.git
> can build the kernel with this series (I tested at dca43a1c82f1).
>
> [1]: https://lore.kernel.org/all/20240717-sparc-cflags-v2-0-259407e6eb5f@protonmail.com/
> [2]: https://lore.kernel.org/all/20240808-sparc-shr64-v2-1-fd18f1b2cea9@protonmail.com/
>
> Cheers,
> Nathan


2/2 should update the "Supported Architectures"
of Documentation/kbuild/llvm.rst if this is adding a new architecture support.




--
Best Regards
Masahiro Yamada