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

[Vladimir Radosavljevic <Vladimir dot Radosavljevic at imgtec dot com>]

Hi Cary,

> If I'm reading your patch correctly, your new
> relocate_special_relocatable doesn't need to look back when processing
> the LO16 relocs, but does need to look forward when processing the
> HI16 relocs. So the lists used by Target::Scan::local() wouldn't help
> here. (Did you mean Target::Scan instead of Target::Relocate? I don't
> see any need to find paired relocs in Target::Relocate.)

I was referring to lists (hi16_relocs, got16_relocs and pchi16_relocs) in
Mips_relocate_functions which are used in Target::Relocate.
Look ahead to the paired LO16 while processing a HI16, or look back to the
paired HI16 while processing a LO16 are two approaches for computing AHL addend
for HI16 relocs.  If you think that 'look ahead' is a better approach, we can
remove lists in Mips_relocate_functions and use get_lo16_rel_addend also in
Target::Relocate::relocate, or if you think that 'look back' is a better
approach, we can move those lists into the class Mips_relobj to fix problem with
--threads and update current patch to use them.
What do you think we should do?

Sorry for not giving more information about this in the patch description!

> 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.

> You should apply for write permission to the binutils repo. Write to
> overseers@sourceware.org and name me as your sponsor. Thanks for all
> your work keeping the MIPS port up to date!

I have filled out the form (https://sourceware.org/cgi-bin/pdw/ps_form.cgi),
because I didn't have account on sourceware.org.
Thanks for all your reviews!

Regards,
Vladimir