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


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:

> dynsym table - dynamic symbol order
> ----
> For mapping unresolvable IFUNC references to IPLT stubs, all IFUNC symbols
> must be sorted to appear contiguous within the dynamic symbol table. However,
> the order of symbols in the dynamic symbol table also controls the order of
> entries in the GOT and that order is defined as:
> - local GOT references
> - normal global GOT entries
> - reloc-only global GOT entries
>
> 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
>
> In this way, the relative meta-order of the 3 categories of GOT entries is
> maintained. The first contiguous sequence of IFUNC symbols is marked by the
> tag MIPS_IFUNC_INDX, with MIPS_IPLT pointing to the start address of the
> corresponding IPLT stub sequence. The 2nd contiguous sequence is marked by
> the tag MIPS_IFUNCREL_INDX, with MIPS_IPLTREL pointing to the start address of
> the corresponding stub sequence. The 2nd sequence and its dynamic tags are
> only needed in the multi-GOT case, where a single primary GOT is insufficient.

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:

  https://sourceware.org/ml/binutils/2013-12/msg00061.html

E.g. it may be that in future someone wants to add priorities to ifuncs,
so that the user can control the order in which ifuncs are called.
If we have ifunc relocations being applied explicitly, we can always
sort them as required.  If instead we divide the ifuncs into three groups,
as above, we will always be limited by that classification.

Thanks,
Richard


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