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

[Cary Coutant <ccoutant@gmail.com>]

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

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 did think about putting the info in Mips_relobj, but then you'll
need an ugly static_cast to convert the Sized_relobj_file* in relinfo.
But I don't think that would even help you here, since you need to
look forward. Right?

I think for now, you could go ahead and use get_lo16_rel_addend() as
you've written it, but instead of changing the function prototype,
just calculate reloc_count from what you have in relinfo, as in
Relocate::relocate().

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

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

I should warn you that I'll be gone for the next three weeks, with
limited access to email. Sorry we couldn't get this patch in before I
left.

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!

-cary