Re: [RFC] ifunc suck, use ufunc.

[Rich Felker <dalias at libc dot org>]

On Mon, May 25, 2015 at 03:43:23AM +0200, Szabolcs Nagy wrote:
> * OndÅej BÃlka <neleai@seznam.cz> [2015-05-24 23:38:58 +0200]:
> > A main benefit would be interlibrary constant folding. Why waste cycles
> > on reinitializing constant, just save it to ufunc structure. Resolver 
> > then could precompute tables to improve speed.
> > 
> > As interposing these you would need to interpose resolver.
> > 
> > An gcc support is not needed but we could get something with alternate
> > calling convention as passing resolver struct is common and could be
> > preserved for loops with tail calls.
> > 
> > A future direction could be replace plt and linker with ufunc, it would
> > require adding function string pointer to structure and calling first
> > generic resolver to select specific resolver.
> > 
> > Comments?
> > 
> 
> this makes memset non-async-signal-safe. (qoi issue)
> 
> it is not thread-safe either and would need an acquire
> load barrier on every invocation of memset to fix that
> or the use of thread local storage. (conformance issue)
> 
> (in the example only resolve->fn is modified and idempotently,
> this would work in practice but as soon as ->data is accessed
> too the memory ordering guarantees are required.. which can
> be made efficient on some archs but only in asm)
> 
> in the example memset is called through the wrong type
> of function pointer: the resolver and resolvee are
> incompatible so this is invalid c, only works in asm.
> 
> it is not clear to me how many such ufunc structs will be
> in a program for a specific function and how their redundant
> initialization is avoided.
> (one for every call site? every tu? every dso?)

Agree with all points. IFUNC sucks, but the reasons that IFUNC sucks
are all exacerbated by this proposal, not fixed.

Rich