More compiler segment generation fixes for unusual layouts. #75
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.
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.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 amemset()
from .sbss to_rambase
.romEnd
:romEnd
, and .bss starts after, .sbss will be extended to the start of .bss, rather than stopping atromEnd
. Previously this resulted in an uninitialized "RAM" block between the segments. (ex: Brigandine)romEnd
and it's specified length puts its end afterromEnd
, then .bss will be extended to its specified length, rather than stopping atromEnd
. 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.