mips address+symbol issue.

cgd@broadcom.com cgd@broadcom.com
Fri Jan 23 21:01:00 GMT 2004

This is case of strange compiler + assembler issues ("surprise
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,
        gp= 0
        .mask   0x40000000,-8
        .fmask  0x00000000,0
        daddiu  $sp,$sp,-16
        sd      $fp,8($sp)
        move    $fp,$sp
        sd      $4,0($fp)
        ld      $3,0($fp)
        dla     $2,a-2000000000
        daddu   $2,$3,$2
        lb      $2,0($2)

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...


More information about the Binutils mailing list