This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] Add IFUNC support for MIPS
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Faraz Shahbazker <faraz dot shahbazker at imgtec dot com>
- Cc: <binutils at sourceware dot org>
- Date: Tue, 23 Jun 2015 19:19:56 +0100
- Subject: Re: [RFC] Add IFUNC support for MIPS
- Authentication-results: sourceware.org; auth=none
- References: <5583540C dot 7070800 at imgtec dot com> <87381jtr31 dot fsf at googlemail dot com> <55899D52 dot 1050000 at imgtec dot com>
Faraz Shahbazker <firstname.lastname@example.org> 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
>>> 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.
> - 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.