This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] ifunc suck, use ufunc.
- From: Rich Felker <dalias at libc dot org>
- To: Szabolcs Nagy <nsz at port70 dot net>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, libc-alpha at sourceware dot org
- Date: Sun, 24 May 2015 22:22:50 -0400
- Subject: Re: [RFC] ifunc suck, use ufunc.
- Authentication-results: sourceware.org; auth=none
- References: <20150524213858 dot GA18221 at domone> <20150525014323 dot GC26188 at port70 dot net>
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