This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: [PATCH][gold] PR 21152: Mips: Handle more relocations in relocatable link
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