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

[Cary Coutant <ccoutant at gmail dot com>]

> This patch adds support for more relocations in relocatable link.  It also
> introduces get_lo16_rel_addend method for finding partnering LO16 relocation
> because there is a problem with current implementation when using --threads
> option.

What problem are you referring to? I'm guessing that you're thinking
you can't use the approach of pushing HI16 relocations onto a list
like Scan::local does with target->got16_addends_, because
relocate_special_relocatable can be called in multiple threads, and
thus cannot update the non-thread-specific list. Well, got16_addends_
ought to be a member of the Target::Scan class, which would make it
thread specific, but it doesn't really matter that much since
Scan::local() and Scan::global() always run single threaded. The same
idea, however, could be used if needed in Target::Relocate, but that
doesn't help with relocate_relocs since there is no Target::Scan or
Target::Relocate equivalent class. It also doesn't help because here
you're trying to look ahead to the paired LO16 while processing a
HI16, while in Scan::local(), it only needs to look back to the paired
HI16 while processing a LO16.

I'm not happy with the potentially quadratic behavior introduced by
get_lo16_rel_addend(), but I guess my real issue isn't with your patch
so much as with the MIPS ABI itself. When the ISA doesn't provide a
sufficiently large operand field for a full embedded addend, ELF
expects you to use RELA relocations. With REL relocations, the linker
is forced to pull ugly stunts like this.

Rather than change the prototype for relocate_special_relocatable(), I
think you'd be better off reimplementing the whole of
relocate_relocs(), similar to what the powerpc port did. If you do
that, you'll be able to make a first pass over the relocs and build a
table of LO16 relocs that you can consult efficiently when processing
the HI16 relocs on the second pass.

-cary