This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] ifunc suck, use ufunc.


* Ond??ej B?lka <neleai@seznam.cz> [2015-05-25 08:11:31 +0200]:
> 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)
> > 
> How, could you elaborate where exactly would it cause problem with
> signals? And dlsym don't count, its just implementation detail. 

with a strict reading of the standard, any access to objects
with static storge duration is invalid from a signal handler
unless their type is volatile sig_atomic_t or lock-free atomic.
(c11/5.1.2.3p5)

in practice it probably works if you only read/write one pointer object,
but if you start using the data member too then the data access can be
interrupted at the wrong time and then calling into the same code path
from the signal handler will cause problems. (so it's not memset that
becomes non-as-safe, but whatever function that calls memset..
assuming each memset call site has its own ufunc struct).


there are other problems: same security issues as with lazy binding
(modifiable function pointers for control flow hijack), interoperability
problems with other hacks (fortify source, interposition), significant
amount of non-sharable data, startup overhead, prevents compiler
optimizations (assuming gcc only sees a call through an ufunc pointer),
debugging issues.

if it can be done as a pure cpp hack (alternate string.h) then you
can experiment with that outside of libc and only if benchmarks show
consistent performance benefits it is worth thinking about.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]