Bug in psp-gcc?

[Bluddy]

I'm pretty sure I found a bug in psp-gcc (or actually in ld). It may be with the specific psp-gcc/ld bfd or it may be in binutils itself.

I'm doing some unusual linking in Scummvm to get dynamic plugins going. I borrowed the method from the Dreamcast Scummvm code, where this works fine. Essentially, I use a custom linker file to put all the shorts (.sbss, .sdata) in one area in my main executable, and then I ask ld to keep the relocation entries with the '-q' option, and to use the symbols from the main executable only. In ScummVM itself I relocate the things in memory.

Things were generally working fine in most games. However, looking into one of the games (Kyrandia), I found the following relocations:

Code: Select all

0000eb44  00000405 R_MIPS_HI16       000fcf60   .rodata
0000eb48  00000406 R_MIPS_LO16       000fcf60   .rodata
0000eb54  00106206 R_MIPS_LO16       08aecb54   _ZN4Kyra14KyraEngine_L
0000eb58  00223d06 R_MIPS_LO16       08aecb5c   _ZN4Kyra14KyraEngine_L

Notice that ld is chaining LO16 relocations after HI16's. However, it's doing something illegal! The LO16 for 08aecb54 is not preceded by a valid HI16 entry! Argh!

[jimparis]

From http://techpubs.sgi.com/library/manuals ... 58-001.pdf page 47:

An R_MIPS_HI16 must be followed immediately by an R_MIPS_LO16 relocation record in a SHT_REL section. The contents of the two fields to be relocated are combined to form a full 32-bit addend AHL. An R_MIPS_LO16 entry which does not immediately follow a R_MIPS_HI16 is combined with the most recent one encountered, i.e. multiple R_MIPS_LO16 entries may be associated with a single R_MIPS_HI16. Use of these relocation types in a SHT_REL section is discouraged and may be forbidden to avoid this complication.

So it sounds valid, although discouraged...