[PATCH 0/2] Clang compatibility improvements for RISC-V

[PATCH 0/2] Clang compatibility improvements for RISC-V

[Yao Zi]

Originally reported by Nathaniel Hourt[1], U-Boot fails to boot on
JH7110 platforms (starfive_visionfive2_defconfig) when building with
Clang.

This series fixes configuration generation with Clang's preprocessor and
add an alternative codepath for RISC-V to access gd to workaround
misoptimization of Clang, which is sufficient for building images for
JH7110 boards.

Tested with

- starfive_visionfive2_defconfig
- qemu-riscv64_smode_defconfig
- sifive_unleashed_defconfig

built with either GCC 14 or LLVM 19.

Note that images built with LLVM lld are still broken and binutils ld
has to be used for now. To test the changes on JH7110 platforms, this
patch[2] must be applied for SPL to function.

[1]: https://lore.kernel.org/u-boot/932979cb47c4fded7ac19216ca172504@nathaniel.land/
[2]: https://lore.kernel.org/all/20250330162421.238483-1-heinrich.schuchardt@canonical.com/

Yao Zi (2):
  Makefile: Strip leading spaces when preprocessing generated_defconfig
  riscv: Access gd with inline assembly when building with LTO or Clang

 arch/riscv/cpu/cpu.c                 |  6 ++++++
 arch/riscv/include/asm/global_data.h | 19 +++++++++++++++++++
 common/board_r.c                     |  4 +++-
 common/init/board_init.c             |  7 +++++--
 scripts/kconfig/Makefile             |  1 +
 5 files changed, 34 insertions(+), 3 deletions(-)

-- 
2.49.0

[PATCH 1/2] Makefile: Strip leading spaces when preprocessing generated_defconfig

[Yao Zi]

Clang's preprocessor may emit extra spaces for lines starting with '#'.
Lines with these extra characters cannot be handled by Kconfig and will
be ignored with warnings like,

        unexpected data:  # CONFIG_OF_BOARD_FIXUP is not set

Those options that is expected to be assigned explicitly with N will be
set to the default value, messing up board configurations.

Let's sed these spaces away to ensure board configurations could be
correctly generated with Clang.

Fixes: 2027e99e61a ("Makefile: Run defconfig files through the C preprocessor")
Reported-by: Nathaniel Hourt <I@nathaniel.land>
Signed-off-by: Yao Zi <ziyao@disroot.org>
---
 scripts/kconfig/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 079add4d5da..ba30652f01a 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -94,6 +94,7 @@ endif
 
 %_defconfig: $(obj)/conf
 	$(Q)$(CPP) -nostdinc -P -I $(srctree) -undef -x assembler-with-cpp $(srctree)/arch/$(SRCARCH)/configs/$@ -o generated_defconfig
+	$(Q)sed -i -e 's/^[[:space:]]//' generated_defconfig
 	$(Q)$< $(silent) --defconfig=generated_defconfig $(Kconfig)
 
 # Added for U-Boot (backward compatibility)
-- 
2.49.0

Re: [PATCH 1/2] Makefile: Strip leading spaces when preprocessing generated_defconfig

[Heinrich Schuchardt]

Am 27. April 2025 16:50:10 MESZ schrieb Yao Zi <ziyao@disroot.org>:
>Clang's preprocessor may emit extra spaces for lines starting with '#'.
>Lines with these extra characters cannot be handled by Kconfig and will
>be ignored with warnings like,
>


Do you have an example for reprocing the issue?
Is there an understanding why Clang behaves in this way?

Best regards 

Heinrich 

>        unexpected data:  # CONFIG_OF_BOARD_FIXUP is not set
>
>Those options that is expected to be assigned explicitly with N will be
>set to the default value, messing up board configurations.
>
>Let's sed these spaces away to ensure board configurations could be
>correctly generated with Clang.
>
>Fixes: 2027e99e61a ("Makefile: Run defconfig files through the C preprocessor")
>Reported-by: Nathaniel Hourt <I@nathaniel.land>
>Signed-off-by: Yao Zi <ziyao@disroot.org>
>---
> scripts/kconfig/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
>index 079add4d5da..ba30652f01a 100644
>--- a/scripts/kconfig/Makefile
>+++ b/scripts/kconfig/Makefile
>@@ -94,6 +94,7 @@ endif
> 
> %_defconfig: $(obj)/conf
> 	$(Q)$(CPP) -nostdinc -P -I $(srctree) -undef -x assembler-with-cpp $(srctree)/arch/$(SRCARCH)/configs/$@ -o generated_defconfig
>+	$(Q)sed -i -e 's/^[[:space:]]//' generated_defconfig
> 	$(Q)$< $(silent) --defconfig=generated_defconfig $(Kconfig)
> 
> # Added for U-Boot (backward compatibility)

Re: [PATCH 1/2] Makefile: Strip leading spaces when preprocessing generated_defconfig

[Yao Zi]

On Sun, Apr 27, 2025 at 05:19:04PM +0200, Heinrich Schuchardt wrote:
> Am 27. April 2025 16:50:10 MESZ schrieb Yao Zi <ziyao@disroot.org>:
> >Clang's preprocessor may emit extra spaces for lines starting with '#'.
> >Lines with these extra characters cannot be handled by Kconfig and will
> >be ignored with warnings like,
> >
> 
> 
> Do you have an example for reprocing the issue?

Sure,

	clang-19 -E -nostdinc -P -I . -undef -x assembler-with-cpp \
		configs/starfive_visionfive2_defconfig

or a smaller example for demonstrating the behaviour,

	cat << EOF | clang -E -P -x assembler-with-cpp -
	# comment line
	normal line
	EOF

and you could see the strange indentation. For reproducing the exact
Kconfig warnings,

	make ARCH=riscv \
		CC='clang-19 --target=riscv64-unknown-linux-musl' \
		starfive_visionfive2_defconfig

(Clang is called clang-19 on my machine)

> Is there an understanding why Clang behaves in this way?

Sadly I have no idea. I guess it may serve for improving
human-readability of the preprocessed output.

This piece of Makefile (processing defconfigs with C preprocessor) is
U-Boot specific and doesn't exist in Linux kernel, thus it's unlikely
to have someone noted the bahaviour difference of preprocessors before.

Honestly saying sedding the output isn't a clean solution, but I cannot
come up with a better way. It'll be nice to have a flag to control the
format of output, but I didn't find one.

Am looking forward to further suggestions and documentation on this.

> Best regards 
> 
> Heinrich 

Thanks,
Yao Zi

> >        unexpected data:  # CONFIG_OF_BOARD_FIXUP is not set
> >
> >Those options that is expected to be assigned explicitly with N will be
> >set to the default value, messing up board configurations.
> >
> >Let's sed these spaces away to ensure board configurations could be
> >correctly generated with Clang.
> >
> >Fixes: 2027e99e61a ("Makefile: Run defconfig files through the C preprocessor")
> >Reported-by: Nathaniel Hourt <I@nathaniel.land>
> >Signed-off-by: Yao Zi <ziyao@disroot.org>
> >---
> > scripts/kconfig/Makefile | 1 +
> > 1 file changed, 1 insertion(+)
> >
> >diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> >index 079add4d5da..ba30652f01a 100644
> >--- a/scripts/kconfig/Makefile
> >+++ b/scripts/kconfig/Makefile
> >@@ -94,6 +94,7 @@ endif
> > 
> > %_defconfig: $(obj)/conf
> > 	$(Q)$(CPP) -nostdinc -P -I $(srctree) -undef -x assembler-with-cpp $(srctree)/arch/$(SRCARCH)/configs/$@ -o generated_defconfig
> >+	$(Q)sed -i -e 's/^[[:space:]]//' generated_defconfig
> > 	$(Q)$< $(silent) --defconfig=generated_defconfig $(Kconfig)
> > 
> > # Added for U-Boot (backward compatibility)
> 

Re: [PATCH 1/2] Makefile: Strip leading spaces when preprocessing generated_defconfig

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

On Sun, Apr 27, 2025 at 03:46:56PM +0000, Yao Zi wrote:
> On Sun, Apr 27, 2025 at 05:19:04PM +0200, Heinrich Schuchardt wrote:
> > Am 27. April 2025 16:50:10 MESZ schrieb Yao Zi <ziyao@disroot.org>:
> > >Clang's preprocessor may emit extra spaces for lines starting with '#'.
> > >Lines with these extra characters cannot be handled by Kconfig and will
> > >be ignored with warnings like,
> > >
> > 
> > 
> > Do you have an example for reprocing the issue?
> 
> Sure,
> 
> 	clang-19 -E -nostdinc -P -I . -undef -x assembler-with-cpp \
> 		configs/starfive_visionfive2_defconfig
> 
> or a smaller example for demonstrating the behaviour,
> 
> 	cat << EOF | clang -E -P -x assembler-with-cpp -
> 	# comment line
> 	normal line
> 	EOF
> 
> and you could see the strange indentation. For reproducing the exact
> Kconfig warnings,
> 
> 	make ARCH=riscv \
> 		CC='clang-19 --target=riscv64-unknown-linux-musl' \
> 		starfive_visionfive2_defconfig
> 
> (Clang is called clang-19 on my machine)
> 
> > Is there an understanding why Clang behaves in this way?
> 
> Sadly I have no idea. I guess it may serve for improving
> human-readability of the preprocessed output.

This is https://github.com/llvm/llvm-project/issues/78778

-- 
Tom

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

Re: [PATCH 1/2] Makefile: Strip leading spaces when preprocessing generated_defconfig

[Yao Zi]

On Sun, Apr 27, 2025 at 10:16:27AM -0600, Tom Rini wrote:
> On Sun, Apr 27, 2025 at 03:46:56PM +0000, Yao Zi wrote:
> > On Sun, Apr 27, 2025 at 05:19:04PM +0200, Heinrich Schuchardt wrote:
> > > Am 27. April 2025 16:50:10 MESZ schrieb Yao Zi <ziyao@disroot.org>:
> > > >Clang's preprocessor may emit extra spaces for lines starting with '#'.
> > > >Lines with these extra characters cannot be handled by Kconfig and will
> > > >be ignored with warnings like,
> > > >
> > > 
> > > 
> > > Do you have an example for reprocing the issue?
> > 
> > Sure,
> > 
> > 	clang-19 -E -nostdinc -P -I . -undef -x assembler-with-cpp \
> > 		configs/starfive_visionfive2_defconfig
> > 
> > or a smaller example for demonstrating the behaviour,
> > 
> > 	cat << EOF | clang -E -P -x assembler-with-cpp -
> > 	# comment line
> > 	normal line
> > 	EOF
> > 
> > and you could see the strange indentation. For reproducing the exact
> > Kconfig warnings,
> > 
> > 	make ARCH=riscv \
> > 		CC='clang-19 --target=riscv64-unknown-linux-musl' \
> > 		starfive_visionfive2_defconfig
> > 
> > (Clang is called clang-19 on my machine)
> > 
> > > Is there an understanding why Clang behaves in this way?
> > 
> > Sadly I have no idea. I guess it may serve for improving
> > human-readability of the preprocessed output.
> 
> This is https://github.com/llvm/llvm-project/issues/78778

Thanks for the reference! I did a quick search among LLVM's issues
before sending the patch but didn't find anything useful.

Do you think such workaround is acceptable? It seems the link should be
included in commit message as well.

> -- 
> Tom

Thanks,
Yao Zi

Re: [PATCH 1/2] Makefile: Strip leading spaces when preprocessing generated_defconfig

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

On Mon, Apr 28, 2025 at 03:57:27AM +0000, Yao Zi wrote:
> On Sun, Apr 27, 2025 at 10:16:27AM -0600, Tom Rini wrote:
> > On Sun, Apr 27, 2025 at 03:46:56PM +0000, Yao Zi wrote:
> > > On Sun, Apr 27, 2025 at 05:19:04PM +0200, Heinrich Schuchardt wrote:
> > > > Am 27. April 2025 16:50:10 MESZ schrieb Yao Zi <ziyao@disroot.org>:
> > > > >Clang's preprocessor may emit extra spaces for lines starting with '#'.
> > > > >Lines with these extra characters cannot be handled by Kconfig and will
> > > > >be ignored with warnings like,
> > > > >
> > > > 
> > > > 
> > > > Do you have an example for reprocing the issue?
> > > 
> > > Sure,
> > > 
> > > 	clang-19 -E -nostdinc -P -I . -undef -x assembler-with-cpp \
> > > 		configs/starfive_visionfive2_defconfig
> > > 
> > > or a smaller example for demonstrating the behaviour,
> > > 
> > > 	cat << EOF | clang -E -P -x assembler-with-cpp -
> > > 	# comment line
> > > 	normal line
> > > 	EOF
> > > 
> > > and you could see the strange indentation. For reproducing the exact
> > > Kconfig warnings,
> > > 
> > > 	make ARCH=riscv \
> > > 		CC='clang-19 --target=riscv64-unknown-linux-musl' \
> > > 		starfive_visionfive2_defconfig
> > > 
> > > (Clang is called clang-19 on my machine)
> > > 
> > > > Is there an understanding why Clang behaves in this way?
> > > 
> > > Sadly I have no idea. I guess it may serve for improving
> > > human-readability of the preprocessed output.
> > 
> > This is https://github.com/llvm/llvm-project/issues/78778
> 
> Thanks for the reference! I did a quick search among LLVM's issues
> before sending the patch but didn't find anything useful.
> 
> Do you think such workaround is acceptable? It seems the link should be
> included in commit message as well.

I'd like to see if we can get llvm to fix this moving forward first. Can
you please comment on the issue as you're hitting this now too?

-- 
Tom

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

Re: [PATCH 1/2] Makefile: Strip leading spaces when preprocessing generated_defconfig

[Yao Zi]

On Mon, Apr 28, 2025 at 08:49:43AM -0600, Tom Rini wrote:
> On Mon, Apr 28, 2025 at 03:57:27AM +0000, Yao Zi wrote:
> > On Sun, Apr 27, 2025 at 10:16:27AM -0600, Tom Rini wrote:
> > > On Sun, Apr 27, 2025 at 03:46:56PM +0000, Yao Zi wrote:
> > > > On Sun, Apr 27, 2025 at 05:19:04PM +0200, Heinrich Schuchardt wrote:
> > > > > Am 27. April 2025 16:50:10 MESZ schrieb Yao Zi <ziyao@disroot.org>:
> > > > > >Clang's preprocessor may emit extra spaces for lines starting with '#'.
> > > > > >Lines with these extra characters cannot be handled by Kconfig and will
> > > > > >be ignored with warnings like,
> > > > > >
> > > > > 
> > > > > 
> > > > > Do you have an example for reprocing the issue?
> > > > 
> > > > Sure,
> > > > 
> > > > 	clang-19 -E -nostdinc -P -I . -undef -x assembler-with-cpp \
> > > > 		configs/starfive_visionfive2_defconfig
> > > > 
> > > > or a smaller example for demonstrating the behaviour,
> > > > 
> > > > 	cat << EOF | clang -E -P -x assembler-with-cpp -
> > > > 	# comment line
> > > > 	normal line
> > > > 	EOF
> > > > 
> > > > and you could see the strange indentation. For reproducing the exact
> > > > Kconfig warnings,
> > > > 
> > > > 	make ARCH=riscv \
> > > > 		CC='clang-19 --target=riscv64-unknown-linux-musl' \
> > > > 		starfive_visionfive2_defconfig
> > > > 
> > > > (Clang is called clang-19 on my machine)
> > > > 
> > > > > Is there an understanding why Clang behaves in this way?
> > > > 
> > > > Sadly I have no idea. I guess it may serve for improving
> > > > human-readability of the preprocessed output.
> > > 
> > > This is https://github.com/llvm/llvm-project/issues/78778
> > 
> > Thanks for the reference! I did a quick search among LLVM's issues
> > before sending the patch but didn't find anything useful.
> > 
> > Do you think such workaround is acceptable? It seems the link should be
> > included in commit message as well.
> 
> I'd like to see if we can get llvm to fix this moving forward first. Can
> you please comment on the issue as you're hitting this now too?

Sure it should be fixed in LLVM and I've left a comment in the issue.

But even though it's fixed in upstream, it will be nice to have such
compatibility workarounds for some time to keep compatibile with older
Clang toolchains, about which my concern is most.

> -- 
> Tom

Best regards,
Yao Zi

Re: [PATCH 1/2] Makefile: Strip leading spaces when preprocessing generated_defconfig

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2626 bytes --]

On Tue, Apr 29, 2025 at 12:31:29PM +0000, Yao Zi wrote:
> On Mon, Apr 28, 2025 at 08:49:43AM -0600, Tom Rini wrote:
> > On Mon, Apr 28, 2025 at 03:57:27AM +0000, Yao Zi wrote:
> > > On Sun, Apr 27, 2025 at 10:16:27AM -0600, Tom Rini wrote:
> > > > On Sun, Apr 27, 2025 at 03:46:56PM +0000, Yao Zi wrote:
> > > > > On Sun, Apr 27, 2025 at 05:19:04PM +0200, Heinrich Schuchardt wrote:
> > > > > > Am 27. April 2025 16:50:10 MESZ schrieb Yao Zi <ziyao@disroot.org>:
> > > > > > >Clang's preprocessor may emit extra spaces for lines starting with '#'.
> > > > > > >Lines with these extra characters cannot be handled by Kconfig and will
> > > > > > >be ignored with warnings like,
> > > > > > >
> > > > > > 
> > > > > > 
> > > > > > Do you have an example for reprocing the issue?
> > > > > 
> > > > > Sure,
> > > > > 
> > > > > 	clang-19 -E -nostdinc -P -I . -undef -x assembler-with-cpp \
> > > > > 		configs/starfive_visionfive2_defconfig
> > > > > 
> > > > > or a smaller example for demonstrating the behaviour,
> > > > > 
> > > > > 	cat << EOF | clang -E -P -x assembler-with-cpp -
> > > > > 	# comment line
> > > > > 	normal line
> > > > > 	EOF
> > > > > 
> > > > > and you could see the strange indentation. For reproducing the exact
> > > > > Kconfig warnings,
> > > > > 
> > > > > 	make ARCH=riscv \
> > > > > 		CC='clang-19 --target=riscv64-unknown-linux-musl' \
> > > > > 		starfive_visionfive2_defconfig
> > > > > 
> > > > > (Clang is called clang-19 on my machine)
> > > > > 
> > > > > > Is there an understanding why Clang behaves in this way?
> > > > > 
> > > > > Sadly I have no idea. I guess it may serve for improving
> > > > > human-readability of the preprocessed output.
> > > > 
> > > > This is https://github.com/llvm/llvm-project/issues/78778
> > > 
> > > Thanks for the reference! I did a quick search among LLVM's issues
> > > before sending the patch but didn't find anything useful.
> > > 
> > > Do you think such workaround is acceptable? It seems the link should be
> > > included in commit message as well.
> > 
> > I'd like to see if we can get llvm to fix this moving forward first. Can
> > you please comment on the issue as you're hitting this now too?
> 
> Sure it should be fixed in LLVM and I've left a comment in the issue.
> 
> But even though it's fixed in upstream, it will be nice to have such
> compatibility workarounds for some time to keep compatibile with older
> Clang toolchains, about which my concern is most.

Depending on what the LLVM people say, we can say what / how long of a
workaround to keep in.

-- 
Tom

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

[PATCH 2/2] riscv: Access gd with inline assembly when building with LTO or Clang

[Yao Zi]

Similar to AArch64's case, Clang may wrongly fold accesses to gd pointer
which is defined with register qualifier into constants, breaking
various components.

This patch defines gd as a macro when building with Clang or LTO, which
expands to get_gd() that accesses gp pointer in assembly, making RISC-V
ports function properly and preparing for introduction of LTO in the
future. Board initialization code is also adapted for non-assignable gd.

Reported-by: Nathaniel Hourt <I@nathaniel.land>
Signed-off-by: Yao Zi <ziyao@disroot.org>
---
 arch/riscv/cpu/cpu.c                 |  6 ++++++
 arch/riscv/include/asm/global_data.h | 19 +++++++++++++++++++
 common/board_r.c                     |  4 +++-
 common/init/board_init.c             |  7 +++++--
 4 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index 5b31da64cbd..15c4e14599d 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -18,6 +18,7 @@
 #include <asm/hwcap.h>
 #include <asm/cpufeature.h>
 #include <asm/cache.h>
+#include <asm/global_data.h>
 #include <dm/uclass-internal.h>
 #include <linux/bitops.h>
 #include <linux/log2.h>
@@ -746,3 +747,8 @@ __weak int cleanup_before_linux(void)
 
 	return 0;
 }
+
+void arch_setup_gd(gd_t *new_gd)
+{
+	set_gd(new_gd);
+}
diff --git a/arch/riscv/include/asm/global_data.h b/arch/riscv/include/asm/global_data.h
index d356752a56a..47b5e2cfc8f 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -14,6 +14,7 @@
 #include <asm/smp.h>
 #include <asm/u-boot.h>
 #include <compiler.h>
+#include <config.h>
 
 /* Architecture-specific global data */
 struct arch_global_data {
@@ -47,8 +48,26 @@ struct arch_global_data {
 
 #include <asm-generic/global_data.h>
 
+#if defined(__clang__) || CONFIG_IS_ENABLED(LTO)
+
+#define DECLARE_GLOBAL_DATA_PTR
+#define gd			get_gd()
+
+static inline gd_t *get_gd(void)
+{
+	gd_t *gd_ptr;
+
+	__asm__ volatile ("mv %0, gp\n" : "=r" (gd_ptr));
+
+	return gd_ptr;
+}
+
+#else
+
 #define DECLARE_GLOBAL_DATA_PTR register gd_t *gd asm ("gp")
 
+#endif
+
 static inline void set_gd(volatile gd_t *gd_ptr)
 {
 #ifdef CONFIG_64BIT
diff --git a/common/board_r.c b/common/board_r.c
index bc6fd6448c2..4fa092ab596 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -815,7 +815,9 @@ void board_init_r(gd_t *new_gd, ulong dest_addr)
 	if (CONFIG_IS_ENABLED(X86_64) && !IS_ENABLED(CONFIG_EFI_APP))
 		arch_setup_gd(new_gd);
 
-#if !defined(CONFIG_X86) && !defined(CONFIG_ARM) && !defined(CONFIG_ARM64)
+#if defined(CONFIG_RISCV)
+	set_gd(new_gd);
+#elif !defined(CONFIG_X86) && !defined(CONFIG_ARM) && !defined(CONFIG_ARM64)
 	gd = new_gd;
 #endif
 	gd->flags &= ~GD_FLG_LOG_READY;
diff --git a/common/init/board_init.c b/common/init/board_init.c
index a06ec1caa2c..2a6f39f51ad 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -13,8 +13,11 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-/* Unfortunately x86 or ARM can't compile this code as gd cannot be assigned */
-#if !defined(CONFIG_X86) && !defined(CONFIG_ARM)
+/*
+ * Unfortunately x86, ARM and RISC-V can't compile this code as gd is defined
+ * as macro and cannot be assigned.
+ */
+#if !defined(CONFIG_X86) && !defined(CONFIG_ARM) && !defined(CONFIG_RISCV)
 __weak void arch_setup_gd(struct global_data *gd_ptr)
 {
 	gd = gd_ptr;
-- 
2.49.0

Re: [PATCH 2/2] riscv: Access gd with inline assembly when building with LTO or Clang

[Leo Liang]

On Sun, Apr 27, 2025 at 02:50:11PM +0000, Yao Zi wrote:
> Similar to AArch64's case, Clang may wrongly fold accesses to gd pointer
> which is defined with register qualifier into constants, breaking
> various components.
> 
> This patch defines gd as a macro when building with Clang or LTO, which
> expands to get_gd() that accesses gp pointer in assembly, making RISC-V
> ports function properly and preparing for introduction of LTO in the
> future. Board initialization code is also adapted for non-assignable gd.
> 
> Reported-by: Nathaniel Hourt <I@nathaniel.land>
> Signed-off-by: Yao Zi <ziyao@disroot.org>
> ---
>  arch/riscv/cpu/cpu.c                 |  6 ++++++
>  arch/riscv/include/asm/global_data.h | 19 +++++++++++++++++++
>  common/board_r.c                     |  4 +++-
>  common/init/board_init.c             |  7 +++++--
>  4 files changed, 33 insertions(+), 3 deletions(-)

Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

Re: (subset) [PATCH 0/2] Clang compatibility improvements for RISC-V

[Tom Rini]

On Sun, 27 Apr 2025 14:50:09 +0000, Yao Zi wrote:

> Originally reported by Nathaniel Hourt[1], U-Boot fails to boot on
> JH7110 platforms (starfive_visionfive2_defconfig) when building with
> Clang.
> 
> This series fixes configuration generation with Clang's preprocessor and
> add an alternative codepath for RISC-V to access gd to workaround
> misoptimization of Clang, which is sufficient for building images for
> JH7110 boards.
> 
> [...]

Applied to u-boot/master, thanks!

[1/2] Makefile: Strip leading spaces when preprocessing generated_defconfig
      commit: 252cd205300c1b9945079c0ae1fe5980ef9dfa56
-- 
Tom