[lld] r204606 - [Mips] Sort R_MIPS_LO16 / R_MIPS_HI16 / R_MIPS_GOT16 before finding

[Richard Sandiford]

Simon Atanasyan <simon at atanasyan.com> writes:
> Author: atanasyan
> Date: Mon Mar 24 09:09:17 2014
> New Revision: 204606
>
> URL: http://llvm.org/viewvc/llvm-project?rev=204606&view=rev
> Log:
> [Mips] Sort R_MIPS_LO16 / R_MIPS_HI16 / R_MIPS_GOT16 before finding
> pairs and calculate AHL addend.

Out of interest, what are you sorting on?  It sounds like it might be
the relocation offset, whereas the relocations need to be tied based
on their original order in .rel.foo.  E.g. for something like:

foo:
	lw      $4,%lo(X)($5)
        ...
	beq	$6,$7,foo
	lui	$5,%hi(X)

the LO16 is against an earlier address, but the assembler makes sure that
the HI16 comes immediately before the LO16 in .rel.text.

It's done that way because the order can't always be reconstructed
otherwise.  E.g. for:

	lui	$4,%hi(X)		A
        ...
	lw	$6,%lo(X+1024)($5)	B
        ...
	lb	$7,%lo(X)($6)		C
	lb	$8,%lo(X+1)($6)		D
        ...
	lui	$5,%hi(X+1024)		E

the order of the incoming .rel.text must be one of:

    ..ACD..EB..
    ..ADC..EB..
    ..EB..ACD..
    ..EB..ADC..

and the linker should honour whichever order it's given.

Sorry if that's what the patch does.  It just sounded odd that any
sorting was necessary.

Thanks,
Richard