[PATCH] Re-enable a hook in MCELFObjectTargetWriter to allow target-specific relocationtable sorting and use this hook for Mips.

[Simon Atanasyan]

On Fri, Mar 13, 2015 at 6:10 PM, Simon Atanasyan <simon at atanasyan.com> wrote:
> On Fri, Mar 13, 2015 at 6:05 PM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>> And it is not possible for a file to mix relocations from these sets? I.E, no file will ever have a R_MIPS16_LO16 and a R_MIPS_HI16? If that is not the case I think there is a bug in gold :-)
>>>
>>> Well, you can have this in a .S file:
>>>
>>> lui  $2,%hi(sym1)
>>> .set mips16
>>> li   $2,%lo(sym1)
>>>
>>> Then relocations would be:
>>> 00000000  00000605 R_MIPS_HI16       00000000   sym1
>>> 00000004  00000669 R_MIPS16_LO16     00000000   sym1
>>>
>>> so the first relocation wouldn't match the second.
>>
>> Simon,
>>
>> It looks like gold would match these. Is that a bug in gold?
>
> Hmm, looks like a bug in gold. It's better to check this code using
> gnu bfd linker. I am far from a computer right now and will be able to
> do the checking in a few hours.

I confirm that gnu bfd linker does not pair R_MIPS_HI16 and
R_MIPS16_LO16 relocations and shows a warning "Can't find matching
LO16 reloc ...". There is a function `mips_elf_add_lo16_rel_addend` to
find a paired relocation and calculate combined addend. This function
distinguishes regular, mips16 and micromips relocations.

-- 
Simon Atanasyan