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

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

Hi Cary,

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

Yes, I'm referring to the problem that you described.
What do you think about moving these lists into the class Mips_relobj?  If I do
that, there is no need to reimplement the whole relocate_relocs() and the same
approach from Target::Relocate can be used (look back to the paired HI16 while
processing a LO16).  Report if there is no matching LO16 reloc can be added at
the end of the Target_mips::relocate_relocs for relocatable link.

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

Relocation section is sorted so each HI16 relocation is followed immediately
by an associated LO16 entry (there can be more than one HI16 reloc for one
LO16), so this approach shouldn't have an impact on performance.

Regards,
Vladimir