This is the mail archive of the binutils@sourceware.org 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


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


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