Gentlemen: this was fixed, although it's a bit of an odd solution. We had to combine both -mno-explicit-relocs and -mno-split-addresses, even though per the MIPS compiler documentation explicit relocs supersedes the split addresses one. Neither of these options on their own work, and it appears as though they're same result individually until you enable both of these. It's really odd, but we're not questioning it since it resolved our issue.
________________________________ From: Andrew Pinski <pins...@gmail.com> Sent: Thursday, February 18, 2021 3:28 PM To: Project Revolution <projectrevo...@hotmail.com> Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>; kenixwhisperw...@gmail.com <kenixwhisperw...@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 >
