Re: [Question] ifunc odering in ELF

[Florian Weimer <fweimer at redhat dot com>]

* 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