Elf2rpl: Fix order of sections inside the .rpx #11
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Maschell
force-pushed
the
elf2rpl_section_order
branch
from
5ba3a6d
to
a81c248
Compare
|
It has been confirmed this fixes conveting .elf of the two RetroArch cores that were producing incompatible .rpx before Waiting for confirmation that .rpl creatinon is still working |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The CafeOS Loader loads .rpx files in chunks of 4MiB. Because of this, it's very important, that the sections of the .rpx are in a order the loader is expecting. Additionally the section offets inside the .rpx should only be in ascending order as is impossible to access the "previous" 4MiB chunk. Only binaries bigger than 4MiB even have a chance running into these, this why we never caught this earlier
But when compiling
fbalpha2012retroarch core for Wii U, the.symtabsection is still in the first 4MiB chunk (at 0x30D6C7), while the loader already loaded section from the second chunk (section 24, .dimport_coreinit at 0x43B67E).This causes this check to fail in the loader:
The pull request tries to make sure the section are in the correct order. I don't really understand the logic for the LOADER section in current elf2rpl implemenation, but just copy pasting the conditions the actual loader is checking for seems to fix the order. Maybe the old elf2rpl implementation had to work around a broken/older wut.ld?
More tests are required but early results look promising. Here is a screenshot of a .elf converted to a .rpx with the patches of the PR.
The binary is not even big enough to be loaded in multiple chunks, but the offsets of the sections are now correct.