Don't use gprel with offset for older aspsx

[dezgeg]

Older versions of aspsx don't seem to use GP-relative addressing for symbol + offset addresses. Here's a scratch demonstrating the problem: https://decomp.me/scratch/5pMP2

The behaviour seems to have changed between 2.67 and 2.77. Diff of DUMPOBJ.EXE for the objects assembled from the same source shows:

--- aspsx-2.67.txt  2024-03-21 00:10:12.529671553 +0200
+++ aspsx-2.77.txt  2024-03-21 00:10:01.209671224 +0200
@@ -1,40 +1,35 @@
 Header : LNK version 2
 46 : Processor type 7
 16 : Section symbol number 1 '.rdata' in group 0 alignment 8
 16 : Section symbol number 2 '.text' in group 0 alignment 8
 16 : Section symbol number 3 '.data' in group 0 alignment 8
 16 : Section symbol number 4 '.sdata' in group 0 alignment 8
 16 : Section symbol number 5 '.sbss' in group 0 alignment 8
 16 : Section symbol number 6 '.bss' in group 0 alignment 8
 16 : Section symbol number 7 '.ctors' in group 0 alignment 8
 16 : Section symbol number 8 '.dtors' in group 0 alignment 8
 6 : Switch to section 2
-2 : Code 192 bytes
-10 : Patch type 30 at offset 4 with (sectstart(4)-[d])
-10 : Patch type 30 at offset 8 with (sectstart(4)-[c])
-10 : Patch type 30 at offset 10 with (sectstart(4)-[b])
-10 : Patch type 82 at offset 18 with ($4+[b])
-10 : Patch type 84 at offset 1c with ($4+[b])
-10 : Patch type 82 at offset 20 with ($6+[b])
-10 : Patch type 84 at offset 24 with ($6+[b])
-10 : Patch type 82 at offset 7c with [b]
-10 : Patch type 84 at offset 80 with [b]
-10 : Patch type 82 at offset 84 with ($18+[b])
-10 : Patch type 84 at offset 88 with ($18+[b])
-10 : Patch type 82 at offset 98 with ($10+[b])
-10 : Patch type 84 at offset 9c with ($10+[b])
-10 : Patch type 82 at offset a0 with ($12+[b])
-10 : Patch type 84 at offset a4 with ($12+[b])
-10 : Patch type 74 at offset a8 with [e]
+2 : Code 172 bytes
+10 : Patch type 100 at offset 4 with [d]
+10 : Patch type 100 at offset 8 with [c]
+10 : Patch type 100 at offset 10 with [b]
+10 : Patch type 100 at offset 18 with ($4+[b])
+10 : Patch type 100 at offset 1c with ($6+[b])
+10 : Patch type 82 at offset 74 with [b]
+10 : Patch type 84 at offset 78 with [b]
+10 : Patch type 100 at offset 7c with ($18+[b])
+10 : Patch type 100 at offset 8c with ($10+[b])
+10 : Patch type 100 at offset 90 with ($12+[b])
+10 : Patch type 74 at offset 94 with [e]
 6 : Switch to section 2
 48 : XBSS symbol number b 'spuCommonAttr' size 28 in section 5
 14 : XREF symbol number e 'SpuSetCommonAttr'
 48 : XBSS symbol number d 'musicVolume' size 4 in section 5
 12 : XDEF symbol number a 'SndSetMusicVolume' at offset 0 in section 2
 48 : XBSS symbol number c 'playingBonusMusic' size 2 in section 5
 0 : End of file

I guess they have introduced entire new relocation type for gprel addressing where the old one couldn't support offsets. (30 is also a type not supported by psyq-obj-parser).

[dezgeg]

Btw, that scratch also has a mismatch due to la not using gprel (on la $4,spuCommonAttr) which goes away if I revert commit 7c1efd5d0cd597a170a6c5dbf3d17576d99bc45c. In case it was reverted to breaking other stuff, maybe that logic should possibly be conditional on aspsx version?

[mkst]

Cool, let me have a look at the scratch and see if I can add some tests and fix this behaviour.

[dezgeg]

Yea, at least for this trivial case la only uses gp since 2.81:

#include <LIBSPU.H>

SpuCommonAttr spuCommonAttr;

void test(void) {
    SpuSetCommonAttr(&spuCommonAttr);
}

ASM:

        .file   1 "test.c"

 # GNU C 2.7.2.SN32.3.7.0002 [AL 1.1, MM 40] Sony Playstation compiled by CC

 # Cc1 defaults:
 # -mgas -msoft-float

 # Cc1 arguments (-G value = 99, Cpu = 3000, ISA = 1):
 # -G99 -w -O3 -fpeephole -ffunction-cse -fpcc-struct-return -fcommon
 # -fgnu-linker -funsigned-char -fverbose-asm -mgas -msoft-float -quiet

gcc2_compiled.:
__gnu_compiled_c:
        .text
        .align  2
        .globl  test

        .comm   spuCommonAttr,40

        .text
        .text
        .ent    test
test:
        .frame  $sp,24,$31              # vars= 0, regs= 1/0, args= 16, extra= 0
        .mask   0x80000000,-8
        .fmask  0x00000000,0
        subu    $sp,$sp,24
        sw      $31,16($sp)
        la      $4,spuCommonAttr
        jal     SpuSetCommonAttr
        lw      $31,16($sp)
        addu    $sp,$sp,24
        j       $31
        .end    test

Dumpobj diff:

--- aspsx-2.79.txt   2024-03-21 19:33:34.079671149 +0200
+++ aspsx-2.81.txt   2024-03-21 19:36:32.379672197 +0200
@@ -1,25 +1,40 @@
 Header : LNK version 2
 46 : Processor type 7
 16 : Section symbol number 1 '.rdata' in group 0 alignment 8
 16 : Section symbol number 2 '.text' in group 0 alignment 8
 16 : Section symbol number 3 '.data' in group 0 alignment 8
 16 : Section symbol number 4 '.sdata' in group 0 alignment 8
 16 : Section symbol number 5 '.sbss' in group 0 alignment 8
 16 : Section symbol number 6 '.bss' in group 0 alignment 8
 16 : Section symbol number 7 '.ctors' in group 0 alignment 8
 16 : Section symbol number 8 '.dtors' in group 0 alignment 8
 28 : Define file number 9 as "Z:\home\dezgeg\kula-decomp\TEST.C"
 6 : Switch to section 2
 6 : Switch to section 2
 6 : Switch to section 2
 6 : Switch to section 2
-2 : Code 40 bytes
-10 : Patch type 82 at offset 8 with [b]
-10 : Patch type 84 at offset c with [b]
-10 : Patch type 74 at offset 10 with [c]
+2 : Code 36 bytes
+10 : Patch type 100 at offset 8 with [b]
+10 : Patch type 74 at offset c with [c]
 6 : Switch to section 2
+60 : End SLD info at offset 0
 48 : XBSS symbol number b 'spuCommonAttr' size 28 in section 5
 14 : XREF symbol number c 'SpuSetCommonAttr'
 12 : XDEF symbol number a 'test' at offset 0 in section 2

[mkst]

Are you aware of any other $gp issues, or shall I get this merged?

[mkst]

I'm just gonna merge this so we can get it deployed on decomp.me - please raise an issue if you know of / encounter any new bugs :) Thanks again for your PR!