This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> 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

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]