Re: [RFC 2.0] Implementing hwcap2

[David Miller <davem at davemloft dot net>]

From: David Miller <davem@davemloft.net>
Date: Mon, 08 Apr 2013 19:49:58 -0400 (EDT)

> From: Roland McGrath <roland@hack.frob.com>
> Date: Mon,  8 Apr 2013 16:29:52 -0700 (PDT)
> 
>>> The issue is that the API exists on the ELF level rather than that
>>> of a traditional C interface.
>> 
>> Indeed.  We have dealt with other such cases more or less adequately
>> (DT_GNU_HASH, STB_GNU_UNIQUE, etc.).  But even those were not as
>> graceful as one would have liked (except perhaps for --hash-style=both,
>> which is pretty thoroughly fine).  And none of those past cases involved
>> an ELF ABI element that had an old-version-ABI to new-version-ABI
>> transition rather than the simpler introduction of a wholly new ABI
>> element.  That's essentially why I am inclined toward the position that
>> STT_GNU_IFUNC is still not really ready for prime time.
> 
> I suppose we should look at setting a bit in the ELF header or
> somesuch.  Something that would be rejected by current libc but which
> we could make the newer libc accept.

It just occured to me that we could use symbol versioning for this,
albeit indirectly.

The idea is to have some symbol that each IFUNC user has to reference,
perhaps in a way that evaluates to a NOP but still generates a
relocation in the final image.

Then we can change the version of that symbol when we change IFUNC
calling conventions.

Perhaps we can automate this by making the assembler emit the
reference to this special symbol any time @gnu_indirection_function is
specified.