[Question] ifunc odering in ELF
Florian Weimer
fweimer@redhat.com
Wed Oct 16 12:55:00 GMT 2019
* Szabolcs Nagy:
> On 20/09/2019 16:51, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> That's was not my impression, I this we should to go this way iff we can't
>>> really make IFUNC reordering work on loader. From your initial work on
>>> the two-phase IFUNC relocation, which prevents us to move forward?
>>
>> No one said, “yes, we do need this feature in the loader”.
>>
>> (Keep in mind that it does not solve all ordering problems, the example
>> in this thread would still break.)
>
> if most "reasonable" ordering issues can be fixed, then
> i think the ordering should be fixed.
>
> but i seem to remember that for it to work it's not enough
> to consider the relocations of a single module,
Current binutils already orders IRELATIVE relocations after all other
relocations. I haven't checked (or don't recall) if the sorting also
treats likely self-bindings specially (ordering them after other
relocations). Beyond that there is little we can do in the link editor
because the problematic scenarios involve preloading, so there's just
not a complete picture and link time.
> but other modules have to be considered (in case of copy relocated
> function pointers? or extern ifunc code in not yet relocated
> modules?).
The patch I posted is global in effect:
<https://sourceware.org/ml/libc-alpha/2018-06/msg00077.html>
> if relocations have to be processed twice across multiple
> modules then i think the complexity is too much (we need to
> allocate space for the list of relocs that need reprocessing
> etc).
Right, the patch does that. Looks like I read the consensus on the list
correctly. 8-/
I guess I'll keep working on eliminating the remaining relocation
dependencies (and others) in glibc's IFUNC resolvers.
Thanks,
Florian
More information about the Libc-alpha
mailing list