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 fbalpha2012 retroarch core for Wii U, the .symtab section 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).
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.
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
fbalpha2012
retroarch core for Wii U, the.symtab
section 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.