Re: IFUNC resolver scheduling (bugs 21041, 20019)

[Carlos O'Donell <carlos at redhat dot com>]

On 01/26/2017 06:17 AM, Florian Weimer wrote:
> On 01/25/2017 05:36 PM, H.J. Lu wrote:
>> On Wed, Jan 25, 2017 at 5:57 AM, Florian Weimer
>> <fweimer@redhat.com> wrote:
>>> 
>>> In retrospect, adding IFUNCs as a user-visible feature looks like
>>> a mistake, but now we have to live with them.
>>> 
>> 
>> Probably.  Now we are making it even more complex.  Doesn't it make
>> the situation worse?
> 
> The x86-64 IFUNC resolvers rely on relocated data, which breaks
> existing binaries which worked before.  I'm trying to fix that.
> 
> Would you prefer that we rolled back the IFUNC resolver changes
> instead?  I have seen zero movement in that direction, so I assumed
> you would not consider this approach acceptable.
> 
> And it's not just x86-64.  I don't see a coordinated effort to comply
> with the requirements on IFUNC resolvers spelled out here:
> 
> <https://sourceware.org/glibc/wiki/GNU_IFUNC>
> 
> (And this document is not particularly helpful as developer
> documentation.)

A coordinated effort is something that we, you, H.J., me need to create
and adhere to :-)

I wrote the document with the intent to coordinate all glibc developers
around a plan to enhance IFUNC to the point where it becomes a real
feature or we decide to remove it from the public interface.

My opinion is that IFUNC is a useful feature, but just needs better
documentation of the restrictions and tooling to support developers.

By it's nature it is a very low-level feature, and we may indeed need to
talk about individual machine restrictions.

-- 
Cheers,
Carlos.