This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [RFC] Add IFUNC support for MIPS
- From: Faraz Shahbazker <faraz dot shahbazker at imgtec dot com>
- To: <binutils at sourceware dot org>, <rdsandiford at googlemail dot com>
- Date: Tue, 23 Jun 2015 10:54:26 -0700
- 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>
Hi Richard,
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.
Regards,
Faraz Shahbazker