Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More compiler segment generation fixes for unusual layouts. #75

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Zinfidel
Copy link
Contributor

@Zinfidel Zinfidel commented May 18, 2024

  • I discovered that the "mysterious" exclusion of the InitHeap function accounted for in my previous patch is just the result of linking NOHEAP.OBJ. I've cleaned up the check for this and updated the comment.
  • Fixed incorrect section RWX flags that resulted from games that had no .sdata section and had .(s)bss sections that came before the end of the program data (Final Fantasy Tactics).
  • The instruction at offset -0x20 being used to determine the start of the .sbss section suffered the same issue as using the initial location of the gp register to determine .sdata in that it would line up with that value most of the time, but not always. This instruction was actually a reference to the symbol _rabackup, which would be the first address in .sbss if the developers linked the appropriate lib/object first. However this is not always the case of course (Soul Reaver), so a more reliable location to read this value is the very first pair of instructions in MAIN.OBJ/NOHEAP.OBJ, which is part of a memset() from .sbss to _rambase.
  • Handle cases where .(s)bss sections span across romEnd:
    • If .sbss starts before romEnd, and .bss starts after, .sbss will be extended to the start of .bss, rather than stopping at romEnd. Previously this resulted in an uninitialized "RAM" block between the segments. (ex: Brigandine)
    • If .bss starts before romEnd and it's specified length puts its end after romEnd, then .bss will be extended to its specified length, rather than stopping at romEnd. Previously, .bss would just be cut short. (ex: Metal Gear Solid)

I believe that this strange disconnect between the header information and seemingly the actual data layout for games is entirely due to small data optimization (gp) by the linker. However I will admit that I can't reconcile that with the fact that linker would be responsible for creating the header to begin with, and I'm not sure why PSYLINK.EXE would handle this situation like this.

As a closing note, I've made a lot of changes to the PSX loader on my own personal branch that I feel are too extensive and perhaps opinionated to make for a good PR, but for possible future bugs/features, my repo may have something already that could help. The MIPS-specific constant propagation analyzer in particular required altering the plugin's SLEIGH metadata to enable it, but it's a huge step up from the basic analyzer.

@Zinfidel Zinfidel marked this pull request as ready for review May 19, 2024 01:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant