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: [RFC] Add IFUNC support for MIPS

Faraz Shahbazker <> 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
>> :-)), 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.


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