Re: [RFC] Add IFUNC support for MIPS

[Richard Sandiford <rdsandiford at googlemail dot com>]

Faraz Shahbazker <faraz.shahbazker@imgtec.com> writes:
> On 06/22/2015 01:40 PM, Richard Sandiford wrote:
>> Thanks for the patch.  I don't want to open old wounds (by which I mean
>> https://sourceware.org/ml/binutils/2013-12/msg00058.html :-)), but why
>> did you go for this scheme:
>
> Although I went through the previous patch-review threads and all of
> Jack's notes, it seems I missed that particular discussion. Funnily, I
> came across it almost immediately after posting the patch. I am going
> through it now and I will rework the patch using some of those
> ideas. However :-) ...
>
> I should point out that my approach was different. As far as IFUNCs are
> concerned, the process of GOT relocation is just vanilla re-basing. The
> actual IFUNC relocations are performed later in the main reloc loop by
> processing IRELATIVE relocs. That order is not controlled by the GOT
> order.
>
>>> To remain consistent with the internal order of entries in the GOT, the
>>> dynamic symbol table is sorted in to 2 contiguous IFUNC sequences, so that
>>> order of GOT entries is:
>>> - local non-IFUNC GOT entries
>>> - local IFUNC GOT entries
>>> - normal global IFUNC GOT entries
>>> - normal global non-IFUNC GOT entries
>>> - reloc-only global non-IFUNC GOT entries
>>> - reloc-only global IFUNC GOT entries
>
> Going through the above discussion, I see problems with this
> arrangement. I realize also that I haven't described it
> accurately. Please ignore this for now, I'll work on it some more.
>
>> The idea of allowing normal relocations in the GOT (as suggested in the
>> earlier threads) seems much simpler and could be applied easily to future
>> extensions.  I'm talking here about the new dynamic tag suggested in:
>
> Sorry that you have to go through this all over again, but I'd like to
> clarify this one point. Which is preferable?
> - Earlier approach: perform IRELATIVE relocs implicitly for symbols in
> shared objects while performing the GOT relocation.
> vs. 
> - Current proposed: each IRELATIVE reloc is explicitly processed as a
> normal relocation, after all GOT relocations and all other relocations.
>
> I tended towards this approach because of a multi-got test-case where
> the resolver function needs symbols that have REL32 relocations.

Yeah, I agree performing them later is better than original implicit
approach.  But I don't think we gain anything by separating ifunc
relocations from other relocations and tying the layout to the original
ABI GOT scheme.

Thanks,
Richard