Re: MIPS md_apply_fix()(?) problem.

[cgd at broadcom dot com]

"H . J . Lu" <hjl@lucon.org> writes:
> The only differences I have seen are delay slot. Maybe we have
> different kernel source/configuration or I have missed it.

I isolated the problem in arch/mips/kernel/setup.c, FWIW.


> > * Still a real problem for non-"-G 0" code.
> 
> I don't think so unless you also use "gcc -mno-abicalls -fno-pic" or
> you don't use ELF. I compiled my RedHat 7.1 mips port and didn't see
> any problems.

Maybe for linux things are OK, but there's definitely a problem in
general.

I suppose the example below many _imply_ those flags, but they're
definitely not specified on the command line, nor are they often
needed to be specified for random embedded development.

Not all of us have the luxury of being so OS-centric.  8-)


Using gcc 3.0.1 (configured for a mips64-elf-ish target) and compiling
like "mips64-elf-gcc -O2", the (valid and reasonable) C code:

extern int bar[100];

int baz(unsigned long offset)
{
        return *(int *)((char *)&bar[10] + offset);
}

int foo[100] = { 0 };
int bar[100] = { 0 };


produces the valid and AFAICT correct assembly:

        .file   1 "bar.c"
        .text
        .align  2
        .align  3
        .globl  baz
        .text
        .ent    baz
baz:
        .frame  $sp,0,$31               # vars= 0, regs= 0/0, args= 0,
        extra= 0
        .mask   0x00000000,0
        .fmask  0x00000000,0
        lw      $2,bar+40($4)
        j       $31
        .end    baz
        .globl  foo
        .data
        .align  3
        .type   foo,@object
        .size   foo,400
foo:
        .word   0
        .space  396
        .globl  bar
        .align  3
        .type   bar,@object
        .size   bar,400
bar:
        .word   0
        .space  396


Assembled using a "2001-10-10 00:00 UTC"-vintage binutils that
becomes:

   0:   3c020000        lui     v0,0x0
                        0: R_MIPS_HI16  bar
   4:   00441021        addu    v0,v0,a0
   8:   8c4201b8        lw      v0,440(v0)
                        8: R_MIPS_LO16  bar
   c:   03e00008        jr      ra
  10:   00000000        nop


That is obviously wrong.


Since this is the same type of input as the simpler assembly test case
I provided, and the erroneous results are of the same style, and no
fix has been made, I can safely conclude that yes, there's a real
problem in the current binutils.



chris