I couldn't figure it out by reading the docs so I did this by guess and check.
If you want to look at the docs on relocation, I think it's this one: http://www.sco.com/developers/devspecs/mipsabi.pdf
There is a LOPROC+a0 program segment in PSP EBOOTs. If your EBOOT does not have a LOPROC+a0 program segment, then it does not have relocations.
I'm working on Students of Round: The Eternal Legend. Here is the readELF output for the EBOOT so you can see the LOPROC+a0 segment: http://pastebin.com/Hw4kyTpj
Here's what relocation entries look like:
Red is the TARGET and green is the RELOCATION TYPE
I found out that relocation type 0x02000000 just adds 0x8804000 to the target. For other types, experimentation (or someone who understands the docs) will be needed. For relocation type 0x02000000:
1) Load the value at the target. Targets are specified by virtual address. For my EBOOT, the target is in the first program segment (virtual address 0) and that segment has a file offset of 0xC0 so you have to add 0xC0 to the target to get the file address.
2) Add 0x8804000 to that value
3) Zero out the entire relocation entry (8 bytes)
Is it a valid strategy to go through and the EBOOT and unwind all these relocations?
I tried programmatically going through and replacing all the relocations of type 0x02000000 for this EBOOT and it appeared to run normally in PPSSPP (approx 14,000 relocations replaced).
I need to unwind them because there are pointers in this "relocated" data that I need to change. It's easier to unwind the relocations first and then change them and also easier to search for the pointers.
If you want to look at the docs on relocation, I think it's this one: http://www.sco.com/developers/devspecs/mipsabi.pdf
There is a LOPROC+a0 program segment in PSP EBOOTs. If your EBOOT does not have a LOPROC+a0 program segment, then it does not have relocations.
I'm working on Students of Round: The Eternal Legend. Here is the readELF output for the EBOOT so you can see the LOPROC+a0 segment: http://pastebin.com/Hw4kyTpj
Here's what relocation entries look like:
Red is the TARGET and green is the RELOCATION TYPE
I found out that relocation type 0x02000000 just adds 0x8804000 to the target. For other types, experimentation (or someone who understands the docs) will be needed. For relocation type 0x02000000:
1) Load the value at the target. Targets are specified by virtual address. For my EBOOT, the target is in the first program segment (virtual address 0) and that segment has a file offset of 0xC0 so you have to add 0xC0 to the target to get the file address.
2) Add 0x8804000 to that value
3) Zero out the entire relocation entry (8 bytes)
Is it a valid strategy to go through and the EBOOT and unwind all these relocations?
I tried programmatically going through and replacing all the relocations of type 0x02000000 for this EBOOT and it appeared to run normally in PPSSPP (approx 14,000 relocations replaced).
I need to unwind them because there are pointers in this "relocated" data that I need to change. It's easier to unwind the relocations first and then change them and also easier to search for the pointers.
