Re: [RFC 2.0] Implementing hwcap2

[Roland McGrath <roland at hack dot frob dot com>]

> The existing calling convention has several glibc releases worth of
> exposure, plus it's the one in use on all Linux distributions.
> 
> I frankly don't think we can safely change it for any target, and at
> the same time expect any level of adoption outside of glibc
> whatsoever.

The notion that it might be acceptable to make an incompatible change is
predicated on the supposition that IFUNC resolver arguments are not used
anywhere outside libc itself today and that other things using them for
the machine in question won't happen (or might as well be delayed) until
a new libc release is made and deployed to places where people might
build such other things.  I maintain that the truth of this supposition
differs by machine.  It's up to you to say how it is for sparc.

I think it's already somewhat questionable how ready it really is for
adoption outside of libc.  The constraints on what you can do in
resolver functions are quite arcane and subtle.  They're straightforward
in the context of understanding the implementation thoroughly: you can't
do anything that requires dynamic relocs or call anything that might
depend on dynamic relocs.  But this is rather difficult to articulate as
a clear specification for someone writing a resolver function, and
especially so if they'll do it in C rather than assembly.  (Alan Modra
has written about this in some more detail, but I don't recall where.)

We have hitherto been fairly cavalier about the introduction of the
feature.  But I think its nature dictates that we take a much more
deliberate approach.  In particular, there is no plausible means I can
think of by which we can version this interface like we do normal
function interfaces.

Given GCC 4.8's "ifunc" attribute support, the cat may be substantially
already out of the bag.  But I think we should figure out what we can do
to improve the situation.


Thanks,
Roland