[PATCH 1/2] arm64: Remove .inst workarounds after binutils bump

Marc Zyngier maz at kernel.org
Mon Jun 9 09:45:34 PDT 2025


On 2025-06-07 11:40, Marc Zyngier wrote:
> Binutils version up to (and including) 2.25 have a pathological
> behaviour when it comes to mixing .inst directive and arithmetic
> involving labels. The assembler complains about non-constant
> expressions and compilation stops pretty quickly.
> 
> Now that our base binutils version is 2.30, we can drop the hackish
> workarounds we had in both the alternative and sysreg code.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  arch/arm64/Kconfig                          |  3 ---
>  arch/arm64/Makefile                         |  4 ---
>  arch/arm64/include/asm/alternative-macros.h | 28 ++++++++-------------
>  arch/arm64/include/asm/sysreg.h             | 21 ----------------
>  tools/arch/arm64/include/asm/sysreg.h       | 21 ----------------
>  5 files changed, 11 insertions(+), 66 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 55fc331af3371..95697700f1992 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -404,9 +404,6 @@ config ARCH_SUPPORTS_UPROBES
>  config ARCH_PROC_KCORE_TEXT
>  	def_bool y
> 
> -config BROKEN_GAS_INST
> -	def_bool !$(as-instr,1:\n.inst 0\n.rept . - 1b\n\nnop\n.endr\n)
> -
>  config BUILTIN_RETURN_ADDRESS_STRIPS_PAC
>  	bool
>  	# Clang's __builtin_return_address() strips the PAC since 12.0.0
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 73a10f65ce8bc..212bf394ea43f 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -29,10 +29,6 @@ cc_has_k_constraint := $(call try-run,echo				\
>  		return 0;						\
>  	}' | $(CC) -S -x c -o "$$TMP" -,,-DCONFIG_CC_HAS_K_CONSTRAINT=1)
> 
> -ifeq ($(CONFIG_BROKEN_GAS_INST),y)
> -$(warning Detected assembler with broken .inst; disassembly will be 
> unreliable)
> -endif
> -
>  # The GCC option -ffreestanding is required in order to compile code 
> containing
>  # ARM/NEON intrinsics in a non C99-compliant environment (such as the 
> kernel)
>  CC_FLAGS_FPU	:= -ffreestanding
> diff --git a/arch/arm64/include/asm/alternative-macros.h
> b/arch/arm64/include/asm/alternative-macros.h
> index c8c77f9e36d60..61c2cbe618b9f 100644
> --- a/arch/arm64/include/asm/alternative-macros.h
> +++ b/arch/arm64/include/asm/alternative-macros.h
> @@ -40,17 +40,6 @@
>  /*
>   * alternative assembly primitive:
>   *
> - * If any of these .org directive fail, it means that insn1 and insn2
> - * don't have the same length. This used to be written as
> - *
> - * .if ((664b-663b) != (662b-661b))
> - * 	.error "Alternatives instruction length mismatch"
> - * .endif
> - *
> - * but most assemblers die if insn1 or insn2 have a .inst. This should
> - * be fixed in a binutils release posterior to 2.25.51.0.2 (anything
> - * containing commit 4e4d08cf7399b606 or c1baaddf8861).
> - *
>   * Alternatives with callbacks do not generate replacement 
> instructions.
>   */
>  #define __ALTERNATIVE_CFG(oldinstr, newinstr, cpucap, cfg_enabled)	\
> @@ -65,8 +54,9 @@
>  	"663:\n\t"							\
>  	newinstr "\n"							\
>  	"664:\n\t"							\
> -	".org	. - (664b-663b) + (662b-661b)\n\t"			\
> -	".org	. - (662b-661b) + (664b-663b)\n\t"			\
> +	".if ((664b-663b) != (662b-661b))\n"				\
> +	".error \"Alternatives instruction length mismatch\"\n"		\
> +	".endif\n"							\
>  	".previous\n"							\

It appears[1] that clang decided to somehow mimic the broken GAS
behaviour with its integrated assembler, and is unable to assemble
the above until some version of clang 19 (both clang 17 and 18, as
available in Debian trixie, appear to be broken).

Passing "CLANG_FLAGS=-no-integrated-as" obviously works, but that's
not exactly desirable.

On the plus side, the test that drives BROKEN_GAS_INST doesn't fire
on any of the clang versions, so we can still drop that.

I'll repost an updated version towards the end of the week.

          M.

[1] https://lore.kernel.org/all/202506091850.ZQDMasOg-lkp@intel.com/
-- 
Jazz is not dead. It just smells funny...



More information about the linux-arm-kernel mailing list