Re: [RFC 2.0] Implementing hwcap2

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

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

This is exactly the sort of "creativity" I had in mind.  (I figured
the thing we'd come up with would involve a gratuitous reference to a
versioned ld.so symbol.)  But I still haven't worked through the
details of a particular scheme.

> 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.

This would fit well with giving the public API a typedef for the IFUNC
resolver function signature.  (I suggested this idea earlier, the
point being that source code would write "static ifunc_resolver_t
foo;" before the definition of foo to get type checking.)  We could
provide some magic macro or suchlike, that serves both to do a
compile-time type check on the resolver function and to generate the
dynamic reloc that constitutes the runtime ld.so compatibility check.

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

Using actual symbol versioning (i.e. different versions of the same
symbol name) for this means that compiling against a new libc will
always produce a binary that requires that libc's most-current IFUNC
protocol.  Alternatively, it could be a different symbol name for each
future update.  That makes it possible for given source code to
produce a binary that only ever requires (for reason of IFUNC
protocol) a libc as new as what the source code was written to
presume.  (This is an even more forgiving compatibility regime than we
use for normal functions that get new symbol versions.)  It's also
probably the most reasonable way to have the aforementioned macro to
generate the reference and do a compile-time type check support a
source-compatible version.

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

I doubt that's a good idea.  It would mean that a new binutils and a
gcc>=4.8 would not be able to support __attribute__ ((ifunc)) at all
when compiling against a glibc<=2.17.


Thanks,
Roland