Binary Loader's bug

[neur0n]

I found a bug in the Binary Loader.
This bug, h.bin will remain open.

Look at loader.s code.

Code: Select all

move $a0, $v0		/* set the return value of the function for arg0 of the next function */

lui $a1, 0x08D2 
lui $a2, 1		
jal 0x08A88578		/* sceIoRead */
nop

jal 0x08A88590		/* sceIoClose   <-- a0 has lost ! */
nop

sceIoClose needs file-uid. It must be stored in $a0.
But $a0 value has been already lost when call sceIoRead .
sceIoClose can not close h.bin!

So I suggest to edit code like this.

Code: Select all

move $a0, $v0		/* set the return value of the function for arg0 of the next function */

lui $a1, 0x08D2 
lui $a2, 1		
jal 0x08A88578		/* sceIoRead */
move $s0, $a0		/*Backup $a0 value*/

jal 0x08A88590		/* sceIoClose */
move $a0, $s0		/*Restore $a0 value*/

If you want to confirm that opened file status , start psplink and type "uidlist Iob".

Advertising

[wololo]

Thanks. Hmm, it means we'll need to update all the save files :/

Advertising

[JJS]

I added this code to the SVN in R107. Thank you neur0n!

Together with the addition of two more sceKernelReleaseSubIntrHandler() calls in FreeMem(), this fixes Mobile Assault on Patapon 2.

[m0skit0]

Bad calling interface. $aX should not be modified by callee. Thumbs down Sony!

[coyotebean]

Bad calling interface. $aX should not be modified by callee. Thumbs down Sony!

The spec of EABI states that only "s" registers need to be preserved by callee.
mips eabi documentation http://www.cygwin.com/ml/binutils/2003-06/msg00436.html

[m0skit0]

SDK function prototypes state that variables are passed by value and not by reference.

[coyotebean]

SDK function prototypes state that variables are passed by value and not by reference.

C prototypes doesn't 100% applies to assembly. e.g. at assembly level, a function only returns a 32-bit value in $v0 for "C" return value of byte/short/int. The compiler generate codes to deal with it. You can see that most routines will push "s" registers to the stack and save the arguments (a0-a3,t0-t3) in "s" registers if the value needed to be used repeatedly.

[m0skit0]

C prototypes doesn't 100% applies to assembly

You're wrong. SDK prototypes (whatever the high language used) MUST apply to assembly 100%, otherwise it makes no sense to have those prototypes. That's the compiler duty. I understand here that either Sony's compiler or SDK is faulty.

[Nymphaea]

Technically, the prototypes do hold. Remember that $a0 is a register, not a variable, when assembled from C the program probably reloads all the arguments before each function from the actual variable. You just have to get used to the wierdness of MIPS I guess. I'm mostly not used to the way the stack works, I miss push(a) and pop(a)

[m0skit0]

when assembled from C the program probably reloads all the arguments before each function from the actual variable

Callee should save all arguments into the stack if he's gonna change their values, and then restore them before returning to caller.

You just have to get used to the wierdness of MIPS I guess

Sorry, but x86 is WAY weirder than MIPS.

'm mostly not used to the way the stack works, I miss push(a) and pop(a)

Disagree as well. I prefer having clear instructions than two pseudo-instruction that only hide what's the processor actually doing (just like CALL on x86 as well). It way more confuse. That's why MIPS is RISC and Intel's nonsense is definitely CISC.