Fix an issue in call_o32() where the upper 32-bit half of incoming n64 
stack arguments is fetched and used for outgoing o32 stack arguments on 
big-endian platforms.

This code was adapted from arch/mips/dec/prom/call_o32.S which was meant 
for a little-endian platform only and therefore using 32-bit loads from 
64-bit stack slot locations holding incoming stack arguments resulted in 
correct values being retrieved for data that is expected to be 32-bit.  

This works on little-endian platforms where the lower 32-bit half of the 
64-bit value is located at every 64-bit stack slot location.  However on 
big-endian platforms the lower 32-bit half is instead located at offset 
4 from every 64-bit stack slot location.

So to fix the issue the offset of 4 would have to be used on big-endian 
platforms only, or alternatively a 64-bit load from the 64-bit stack 
slot location can be used across the board, as the subsequent 32-bit 
store to the corresponding outgoing stack argument slot will correctly 
truncate the value and cause no unpredictable result.  We already take 
advantage of this architectural feature for the incoming arguments held 
in $a6 and $a7 registers, since the o32 wrapper does not know how many 
incoming arguments there are and consequently propagates incoming data 
which may not be 32-bit.

Since this code is generally supposed to be used with the stack located 
in cached memory there is no extra overhead expected for 64-bit loads as 
opposed to 32-bit ones, so pick this variant for code simplicity.

Fixes: 231a35d37293 ("[MIPS] RM: Collected changes")
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
---
 arch/mips/fw/lib/call_o32.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

linux-mips-call-o32-endian.diff
Index: linux-macro/arch/mips/fw/lib/call_o32.S
===================================================================
--- linux-macro.orig/arch/mips/fw/lib/call_o32.S
+++ linux-macro/arch/mips/fw/lib/call_o32.S
@@ -74,7 +74,7 @@ NESTED(call_o32, O32_FRAMESZ, ra)
 		PTR_LA		t1,6*O32_SZREG(fp)
 		li		t2,O32_ARGC-6
 1:
-		lw		t3,(t0)
+		ld		t3,(t0)
 		REG_ADDU	t0,SZREG
 		sw		t3,(t1)
 		REG_SUBU	t2,1

On Sat, May 02, 2026 at 12:14:20AM +0100, Maciej W. Rozycki wrote:
> Fix an issue in call_o32() where the upper 32-bit half of incoming n64 
> stack arguments is fetched and used for outgoing o32 stack arguments on 
> big-endian platforms.
> 
> This code was adapted from arch/mips/dec/prom/call_o32.S which was meant 
> for a little-endian platform only and therefore using 32-bit loads from 
> 64-bit stack slot locations holding incoming stack arguments resulted in 
> correct values being retrieved for data that is expected to be 32-bit.  
> 
> This works on little-endian platforms where the lower 32-bit half of the 
> 64-bit value is located at every 64-bit stack slot location.  However on 
> big-endian platforms the lower 32-bit half is instead located at offset 
> 4 from every 64-bit stack slot location.
> 
> So to fix the issue the offset of 4 would have to be used on big-endian 
> platforms only, or alternatively a 64-bit load from the 64-bit stack 
> slot location can be used across the board, as the subsequent 32-bit 
> store to the corresponding outgoing stack argument slot will correctly 
> truncate the value and cause no unpredictable result.  We already take 
> advantage of this architectural feature for the incoming arguments held 
> in $a6 and $a7 registers, since the o32 wrapper does not know how many 
> incoming arguments there are and consequently propagates incoming data 
> which may not be 32-bit.
> 
> Since this code is generally supposed to be used with the stack located 
> in cached memory there is no extra overhead expected for 64-bit loads as 
> opposed to 32-bit ones, so pick this variant for code simplicity.
> 
> Fixes: 231a35d37293 ("[MIPS] RM: Collected changes")
> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
> ---
>  arch/mips/fw/lib/call_o32.S |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied to mips-next

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]