[patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs

[Richard Sandiford]

Paul Koning <pkoning@equallogic.com> writes:
> I didn't understand this discussion particularly well, but let me
> toss in an example I just spotted in GCC 3.4.1 RC1 output:
>
> 	.loc 1 93 0
> 	lw	$16,%got(utfile)($28)
> 	lw	$5,%got($LC0)($28)
> 	lw	$25,%call16(fopen)($28)
> 	addiu	$4,$16,%lo(utfile)
> 	jalr	$25
> 	addiu	$5,$5,%lo($LC0)
>
> According to comments in the bfd sources, a %got is treated much like
> a %hi.  So what I see here is two %lo operations that are each paired
> with a %hi (%got) but the matching one is NOT the immediately
> preceding one.
>
> Is this legal?

Yes.  The order of the relocations in the assembly code doesn't matter.
When you use explicit relocs, it's up to the assembler to make sure that
the relocations are listed in the correct order.

(Note that relocations don't have to be in order of increasing
field address.)

> Is this what the discussion is about?

No, it's about what happens when you have more instances of %lo(FOO)
than you have of %hi(FOO) or %got(FOO).

> Will the current toolchain handle it correctly?

Hope so ;)

Richard