as-instr in Kbuild broken for arch/arm

as-instr in Kbuild broken for arch/arm

[Nathan Chancellor]

Hi Masahiro,

I backported commit d5c8d6e0fa61 ("kbuild: Update assembler calls to use
proper flags and language target") to 5.4 due to an upstream clang
change that necessitates this [1] but it causes a failure for as-instr
with arm [2] because arch/arm/Makefile uses '-include asm/unified.h' for
KBUILD_AFLAGS but LINUXINCLUDE is not present in the as-instr command,
resulting in

  <built-in>:1:10: fatal error: 'asm/unified.h' file not found
      1 | #include "asm/unified.h"
        |          ^~~~~~~~~~~~~~~
  1 error generated.

There does not appear to be any uses of as-instr within Kbuild (as
opposed to Kconfig) for arch/arm after commit 541ad0150ca4 ("arm: Remove
32bit KVM host support") in 5.7 but as far as I can tell, it is still
possible to hit this issue in upstream if one were to be added.

I see two obvious solutions but I am not sure what you would prefer.

1. Add LINUXINCLUDE to the as-instr invocation, which would ensure
relative '-include' flags can always be interpreted correctly, but I am
unsure if this has other implications.

diff --git a/scripts/Makefile.compiler b/scripts/Makefile.compiler
index ef91910de265..3dc814f0cae8 100644
--- a/scripts/Makefile.compiler
+++ b/scripts/Makefile.compiler
@@ -38,7 +38,7 @@ as-option = $(call try-run,\
 # Usage: aflags-y += $(call as-instr,instr,option1,option2)
 
 as-instr = $(call try-run,\
-	printf "%b\n" "$(1)" | $(CC) -Werror $(CLANG_FLAGS) $(KBUILD_AFLAGS) -Wa$(comma)--fatal-warnings -c -x assembler-with-cpp -o "$$TMP" -,$(2),$(3))
+	printf "%b\n" "$(1)" | $(CC) -Werror $(CLANG_FLAGS) $(LINUXINCLUDE) $(KBUILD_AFLAGS) -Wa$(comma)--fatal-warnings -c -x assembler-with-cpp -o "$$TMP" -,$(2),$(3))
 
 # __cc-option
 # Usage: MY_CFLAGS += $(call __cc-option,$(CC),$(MY_CFLAGS),-march=winchip-c6,-march=i586)

2. Turn 'asm/unified.h' into an absolute path, which easily fixes this
particular instance but does not prevent it from occurring again. It
seems unlikely that it would because '-include' does not appear to be
too common across the tree but I am always leery of silent failures like
this.

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4808d3ed98e4..e31e95ffd33f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -149,7 +149,7 @@ endif
 # Need -Uarm for gcc < 3.x
 KBUILD_CPPFLAGS	+=$(cpp-y)
 KBUILD_CFLAGS	+=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
-KBUILD_AFLAGS	+=$(CFLAGS_ABI) $(AFLAGS_ISA) -Wa,$(arch-y) $(tune-y) -include asm/unified.h -msoft-float
+KBUILD_AFLAGS	+=$(CFLAGS_ABI) $(AFLAGS_ISA) -Wa,$(arch-y) $(tune-y) -include $(srctree)/arch/arm/include/asm/unified.h -msoft-float
 KBUILD_RUSTFLAGS += --target=arm-unknown-linux-gnueabi
 
 CHECKFLAGS	+= -D__arm__

[1]: https://lore.kernel.org/20250604233141.GA2374479@ax162/
[2]: https://lore.kernel.org/CACo-S-1qbCX4WAVFA63dWfHtrRHZBTyyr2js8Lx=Az03XHTTHg@mail.gmail.com/

Cheers,
Nathan

Re: as-instr in Kbuild broken for arch/arm

[Masahiro Yamada]

On Wed, Jun 18, 2025 at 5:04 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Hi Masahiro,
>
> I backported commit d5c8d6e0fa61 ("kbuild: Update assembler calls to use
> proper flags and language target") to 5.4 due to an upstream clang
> change that necessitates this [1] but it causes a failure for as-instr
> with arm [2] because arch/arm/Makefile uses '-include asm/unified.h' for
> KBUILD_AFLAGS but LINUXINCLUDE is not present in the as-instr command,
> resulting in
>
>   <built-in>:1:10: fatal error: 'asm/unified.h' file not found
>       1 | #include "asm/unified.h"
>         |          ^~~~~~~~~~~~~~~
>   1 error generated.
>
> There does not appear to be any uses of as-instr within Kbuild (as
> opposed to Kconfig) for arch/arm after commit 541ad0150ca4 ("arm: Remove
> 32bit KVM host support") in 5.7 but as far as I can tell, it is still
> possible to hit this issue in upstream if one were to be added.
>
> I see two obvious solutions but I am not sure what you would prefer.

The latter because this is more consistent with the existing cases.

The answer is in LINUXINCLUDE itself.

                -include $(srctree)/include/linux/compiler-version.h \
                -include $(srctree)/include/linux/kconfig.h

If we include them in a relative path, we would do:

                -include linux/compiler-version.h \
                -include linux/kconfig.h


Apparently, we always did this in an absolute path.



-- 
Best Regards
Masahiro Yamada