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.


On Mon, May 25, 2015 at 02:49:19PM +0200, Szabolcs Nagy wrote:
> * 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. 
>
Thanks, you first comment just looked that you glanced over
implementation and as dlsym isn't async-signal safe you claimed that
issue.
 
> 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)
> 
While correct our manual has following comment:

http://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html

In practice, you can assume that int is atomic. You can also assume that
pointer types are atomic; that is very convenient. Both of these
assumptions are true on all of the machines that the GNU C Library
supports and on all POSIX systems we know of.

> 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).
>
That wouldn't be problem as standard gives you bare minimum and you
could exploit architecture knowledge as this is architecture specific
optimization.
if you are careful and don't read data then both writes would be same.

Anyway there is real problem that is bit related. One could create
recursion with resolvers. There is simple solution that solves both
problems. Add fallback implemenation f that dont read data. Then CAS
resolver fn for fallback. Only one resolver would succeed while other
will simply call fallback. Then after succeeding resolver finished he
will write real implemention.

Again this adds cost and question is if its worth benefit.

>
> there are other problems: same security issues as with lazy binding
> (modifiable function pointers for control flow hijack),

Thats already solved techinal detail. In libc you xor function pointer
with random value for randomization.

 interoperability
> problems with other hacks (fortify source, interposition), significant
these already don't work reliably as gcc could optimizes these away for
same reason and why shouldnt it work with fortify source.

> amount of non-sharable data, startup overhead,
Could be solved with profiling. Read previous mail. 

> prevents compiler
> optimizations (assuming gcc only sees a call through an ufunc pointer),
Which is bonus as compiler builtin cause more regressions than their
benefit which is that gcc could sometimes value of string function with
constant arguments.

> debugging issues.
> 
How its different from preexisting situation. With ifunc you would also
be redirected to random assembly according how gcc expands it.

These were just examples that if you add random issue without any
justification I could reject it with same ease. You need to write more
and you could find that isn't problem or that I should do X to avoid it.

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

You will see, I don't see why do you use pure cpp limit as ufuncs are
for selecting optimized assembly. I will just use standard LD_PRELOAD
trick


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