PPU Loader: Fix main()'s envp, move process arguments to stack #14461
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This originally came from that I knew for a while that R1 of main thread is not accurate to realh unlike in other threads, I did not fix it originally when discovered because I was not sure why R1 changes sometimes.
Today it hitted me that it may because the argv and envp are passed on the stack and their size may differ when using different arguments.
So I tested it on realhw, fixing it by moving
argv
andenvp
to stack instead of dynamic memory. Saving a whopping 128KB of RAM as a side effect ;)But this was not playing nice with
envp
, after some reversing it turned out we were emulatingenvp
wrong.Originally, the
argv
andenvp
pointer arrays are 64-bit arrays because CELL is natively a 64-bit processor, but games use 32-bit pointers exclusively. So the workaround embedded in all EBOOT.BIN is to convert the 64-bit array into 32-bit array. This functionality needs to know how many arguments are in each array in total. Total amount ofenvp
arguments is passed in the R6 register to the program but we were always initializaing it with 0 so it could not fix theenvp
array resutling in crashes (because it always pointed to 32-bit nullptr) when dereferencing it!Hwtest: elad335/myps3tests@173d346
Fixes #13014 as it turns out :)