Possibly gcc/ld bug

Possibly gcc/ld bug

[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 ld itself. I'm not sure this is
the right forum to post this, but hopefully the experts can assist me.

I'm working on the PSP (MIPS architecture), doing some unusual linking in
Scummvm to get dynamic plugins going. I borrowed the method from the
Dreamcast Scummvm code, where it works just 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 for the
plugin files with the '-q' option, and to take all the symbols from the main
executable. Within 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:

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 completely illegal since the LO16 for 08aecb54 is not
preceded by a valid HI16 entry! ld got confused by the two address ranges. 

The reason I never came across this before is that this is the first time
the compiler chose to access things in the shorts section using HI/LO16s
instead of GPRELs. I didn't know that was even legal. Since I kept my -G
parameter at the default of 8 (i.e. I dropped it), most games never accessed
the $gp relative section using HI/LO16s. This is the only game that had
arrays of 8 bytes, and I guess the compiler decided it was worth it to just
use HI/LO16s to access them. This means also that if I enlarge my -G
parameter, I'll get more of these issues.
-- 
View this message in context: http://www.nabble.com/Possibly-gcc-ld-bug-tp26112337p26112337.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: Possibly gcc/ld bug

[Ian Lance Taylor]

Bluddy <yotambarnoy@gmail.com> writes:

> Notice that ld is chaining LO16 relocations after HI16's. However, it's
> doing something completely illegal since the LO16 for 08aecb54 is not
> preceded by a valid HI16 entry! ld got confused by the two address ranges. 

While the calculation of a HI16 reloc requires the LO16 reloc, the
reverse is not true: you can calculate LO16 without HI16.  The GNU
toolchain takes advantage of this fact.

Ian