search

devkitPro / wut-tools

GNU General Public License v2.0
11 stars 12 forks source link

Elf2rpl: Fix order of sections inside the .rpx #11

Closed Maschell closed 3 months ago

Maschell commented 3 months ago

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:

grafik grafik

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. grafik The binary is not even big enough to be loaded in multiple chunks, but the offsets of the sections are now correct.

Maschell commented 3 months ago

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