Re: [PATCH] MIPS: replace add and sub instructions in relocate_kernel.S with addiu

[Ralf Baechle <ralf@linux-mips.org>]

On Wed, Jun 17, 2015 at 05:12:50PM +0100, James Cowgill wrote:

> Fixes the assembler errors generated when compiling a MIPS R6 kernel with
> CONFIG_KEXEC on, by replacing the offending add and sub instructions with
> addiu instructions.
> 
> Build errors:
> arch/mips/kernel/relocate_kernel.S: Assembler messages:
> arch/mips/kernel/relocate_kernel.S:27: Error: invalid operands `dadd $16,$16,8'
> arch/mips/kernel/relocate_kernel.S:64: Error: invalid operands `dadd $20,$20,8'
> arch/mips/kernel/relocate_kernel.S:65: Error: invalid operands `dadd $18,$18,8'
> arch/mips/kernel/relocate_kernel.S:66: Error: invalid operands `dsub $22,$22,1'
> scripts/Makefile.build:294: recipe for target 'arch/mips/kernel/relocate_kernel.o' failed
> 
> Signed-off-by: James Cowgill <James.Cowgill@imgtec.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: <stable@vger.kernel.org> # 4.0+
> ---
>  arch/mips/kernel/relocate_kernel.S | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S
> index 74bab9d..c6bbf21 100644
> --- a/arch/mips/kernel/relocate_kernel.S
> +++ b/arch/mips/kernel/relocate_kernel.S
> @@ -24,7 +24,7 @@ LEAF(relocate_new_kernel)
>  
>  process_entry:
>  	PTR_L		s2, (s0)
> -	PTR_ADD		s0, s0, SZREG
> +	PTR_ADDIU	s0, s0, SZREG
>  
>  	/*
>  	 * In case of a kdump/crash kernel, the indirection page is not
> @@ -61,9 +61,9 @@ copy_word:
>  	/* copy page word by word */
>  	REG_L		s5, (s2)
>  	REG_S		s5, (s4)
> -	PTR_ADD		s4, s4, SZREG
> -	PTR_ADD		s2, s2, SZREG
> -	LONG_SUB	s6, s6, 1
> +	PTR_ADDIU	s4, s4, SZREG
> +	PTR_ADDIU	s2, s2, SZREG
> +	LONG_ADDIU	s6, s6, -1

Thanks, applied.

But I was wondering if maybe we should redefine the PTR_ADD, LONG_SUB etc
macros to expand into a signed operation for R6.  While I can't convince
myself it's the right and conceptually clean thing to do, I don't think
it'd be clearly wrong and it might help preventing numersous bugs by
applications that use <asm/asm.h>.  Opinions?

  Ralf