RE: [PATCH][gold] PR 21152: Mips: Handle more relocations in relocatable link

["Maciej W. Rozycki" <macro at imgtec dot com>]

On Tue, 21 Mar 2017, Vladimir Radosavljevic wrote:

> > If this is true, you could limit the forward scan to just a single
> > lookahead. But wouldn't such a restriction severely constrain
> > optimization? (I can imagine optimizations that would separate the
> > HI16 and LO16 relocations by an indefinite number of instructions, and
> > even some that might migrate a LO16 above its paired HI16.)
> 
> Example of assembly file:
> lw $2, %lo(sym)
> lui $2, %hi(sym)
> lui $2, %hi(sym)
> 
> Relocation section:
> 00000008  00000805 R_MIPS_HI16       00000000   sym
> 00000004  00000805 R_MIPS_HI16       00000000   sym
> 00000000  00000806 R_MIPS_LO16       00000000   sym
> 
> As you can see, assembler is sorting relocation section so HI16 relocs come
> before their matching LO16 pair, and we can rely on that in the linker for
> computing AHL addends.  ABI specification says that each HI16 relocation is
> followed immediately by an associated LO16 entry, but in practice more HI16
> relocations can have one matching LO16, and because of that we can't limit
> the forward scan to just a single lookahead.

 NB having multiple HI16 relocs associated with a single LO16 reloc is a 
GNU extension (helping with some cases of optimisation, also imperfect 
ones), however the reverse, that is having multiple LO16 relocs associated 
with a single HI16 reloc, is actually set out there in the SVR4 MIPS psABI 
document, addressing the more common case like:

	lui	$1, %hi(sym)
	lw	$2, %lo(sym)($1)
	lw	$3, %lo(sym + 4)($1)

used to fetch a 64-bit data quantity (of course this LUI and hence its 
associated reloc may also be reordered, e.g. typically scheduled into a 
branch delay slot elsewhere).  Observe that the in-place addend difference 
of 4 between the two LO16 relocs does not matter here for a possible 
borrow from the HI16 part as long as `sym' is naturally aligned.

 The choice of REL as the reloc encoding format was indeed unfortunate 
with the original o32 MIPS ABI, and rectified in the later n64/n32 ABIs, 
which use RELA instead.

  Maciej