Re: GCC generates non-compliant MIPS relocation data? Obscure GNU extension?

[Project Revolution <projectrevotpp@hotmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5299 bytes --]

We do -fno-toplevel-reorders, which implies section anchors are off. We recompiled, but:

...
0000052c  00004505 R_MIPS_HI16       00000000   gSaveContext
00000530  00004506 R_MIPS_LO16       00000000   gSaveContext
00000538  00004705 R_MIPS_HI16       0000057c   func_80A56614
00000b60  00004705 R_MIPS_HI16       0000057c   func_80A56614
0000053c  00004706 R_MIPS_LO16       0000057c   func_80A56614
0000055c  00003304 R_MIPS_26         00000000   osSyncPrintf
00000558  00001305 R_MIPS_HI16       00000160   $LC17
...

...
.word 0x45000538
.word 0x45000B60
...

As seen above, there is still a double HI here, which was present before. Finishing compiling the ROM still results in the same crash due to the bad reloc data.

Sorry, didnt do Reply All last time.

________________________________
From: Andrew Pinski <pinskia@gmail.com>
Sent: Thursday, February 18, 2021 3:28 PM
To: Project Revolution <projectrevotpp@hotmail.com>
Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>; kenixwhisperwind@gmail.com <kenixwhisperwind@gmail.com>
Subject: Re: GCC generates non-compliant MIPS relocation data? Obscure GNU extension?

On Thu, Feb 18, 2021 at 12:15 PM Project Revolution via Gcc
<gcc@gcc.gnu.org> wrote:
>
> Hi GCC folks,
>
> We were working on a decompilation project for a Nintendo 64 title and attempting to enable support for using GCC instead of the emulated IRIX compiler and we ran into a big problem with how GCC generates relocations for the MIPS target which appears to show that GCC is generating non-compliant relocation data for MIPS target.

Try compiling with -fno-section-anchors .
https://gcc.gnu.org/legacy-ml/gcc-help/2009-07/msg00455.html

Thanks,
Andrew

>
> In summary: the Nintendo 64 title has a limited amount of RAM (4MB, 8MB if you add Expansion Pak, which our ROM target uses for debug reasons); in order to accomplish this, the codebase packs actors/objects into overlays which the game determines need to be loaded per room/system transition. Once loaded into RAM, the game applies the overlay's relocations generated at compile time to the code to move the data and code correctly and make sure the jumps and loads get recalculated correctly.
>
> Unfortunately.. there's a problem. Here's the function that applies the relocs to MIPS: https://github.com/zeldaret/oot/blob/master/src/code/relocation.c
>
> While enabling overlays to be recompiled with GCC instead of the IDO compiler, we have found the relocs generated did not guarantee 0x45/0x46 (Hi/lo pairs) pairs to be 1:1, and GCC would share any possible hi/lo in O2 mode. While O0 and O1 gcc overlays will work, or even Og, this is not a solution for an N64 ROM due to limited RAM and space will quickly run out since memory is so tight. While investigating why gcc will optimize relocs, we have found the following:
>
> The MIPS ABI specified at https://refspecs.linuxfoundation.org/elf/mipsabi.pdf on pages 79-80 (page 82 regarding the GP caveat) demands that hi/los be in pairs). Thus, we have found that the reloc data generated erroneously applies the relocation twice. Several LOs following a HI seems to be in a spec, but several HIs following a LO does not. This is causing issues for our relocation due to the relocs being applied incorrectly as a result of non-compliant relocation data. It turned out this reloc optimization is caused by an unmentioned, undocumented GNU extension.
>
> We have found the GNU extension was ONLY ever mentioned here: https://people.freebsd.org/~adrian/mips/20160819-mips-elf-reloc-gcc-5.3-3.diff
>
> Here is the file we compiled: https://github.com/zeldaret/oot/blob/master/src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.c
>
> This is the line we used to compile it:
>
> mips-linux-gnu-gcc -c -O2 -c -G 0 -nostdinc -Iinclude -Isrc -Iassets -Ibuild -I. -DNON_MATCHING=1 -DNON_EQUIVALENT=1 -DAVOID_UB=1 -mno-shared -march=vr4300 -mfix4300 -mabi=32 -mhard-float -mdivide-breaks -fno-stack-protector -fno-common -fno-zero-initialized-in-bss -mno-abicalls -fno-strict-aliasing -fno-inline-functions -fno-inline-small-functions -fno-toplevel-reorder -ffreestanding -fwrapv -Wall -Wextra -g -fno-gcse -fno-cse-follow-jumps -mno-load-store-pairs -mno-explicit-relocs -fno-peephole2 -mips3 -o build/src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.o src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.c
>
> To note, we have tried with and without explicit relocs and with and without peephole2 and with and without mips2/3 and it didnt make a difference: the relocs were still noncompliant per the PDF posted earlier. We need a way to turn this undocumented GNU extension off because it is causing relocs when optimized to not be processed correctly. To note, our use case is attempting to compile this repo with GCC (this file is a test case) but if you were to compile the ROM with the Heishi4 file being compiled as GCC using the above call (make any Makefile alterations to force the object to be GCC), spawn on the SPOT00 map at the start of the game and go inside the castle town area and observe the crash which takes like 60 seconds. This is ultimately what we're trying to fix which following this rabbit hole leads us to this GNU extension in a haystack hunt. Can you guys help us resolve this?
>
> v/r,
> Revo
>

[-- Attachment #2: z_en_heishi4.o --]
[-- Type: application/octet-stream, Size: 365664 bytes --]