2004-01-23 21:00:59 UTC
surprise" 8-). I ran into it testing mipsisa64-elf on real HW.
(strangely, sim didn't flag it, dunno what's up with that.)
I was testing code with and without -mno-explicit-relocs, to see if a
change i made to binutils was OK. (I was using a combined tree w/
sources as of 2004-01-21.)
The problematic test is gcc.c-torture/execute/960321-1.c. I was
testing on a real target board (BCM91250A), with "-Tcfe.ld" as the
linker script. The test binary comes out as EABI64 in that
For the -O0 case, GCC is emitting code like:
.frame $fp,16,$31 # vars= 8, regs= 1/0, args= 0,
What's happening is that the assembler turns that 'dla' into:
14: 3c0288ca lui v0,0x88ca
14: R_MIPS_HI16 a
18: 24426c00 addiu v0,v0,27648
18: R_MIPS_LO16 a
and then at link time A ends in kseg0:
80022808 g O .data 0000000a a
so the final instructions in the object file end up as:
8002020c: 3c0208cd lui v0,0x8cd
80020210: 24429408 addiu v0,v0,-27640
which end up having the effect:
v0 = 0x8cc9408
0x8cc9408 + 2000000000 != 0x(ffffffff)80022808
without -mno-explicit-relocs, the compiler gets it right.
I can think of several possible solutions here:
(1) don't allow GCC to emit "dla sym+offset" for
-mno-explicit-relocs, or maybe just for -mno-explicit-relocs
and the ABIs which stuff 64-bit pointers into 32-bit object
(2) make binutils emit long code sequences for sym + offset when
assembling objects for an ABI which stuffs 64-bit pointers
into 32-bit object files.
(3) punt. (maybe even xfail the test for some MIPS targets w/
It seems to me that (2) is *probably* the right fix, but others'
opinions would be appreciated. I think I'm OK with (3), too, but it
might bite others down the road...