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 2/2] Update prototype of IFUNC resolver for MIPS


On Fri, Sep 04, 2015 at 02:17:56PM +0100, Szabolcs Nagy wrote:
> On 03/09/15 23:03, Faraz Shahbazker wrote:
> > +static int __attribute_used__
> > +dl_ifunc_control (int operation, int value)
> > +{
> ...
> > +          /* Remember the choice for the last compabitle FP ABI.  */
> > +          ifunc_fpabi = in_abi;
> ...

also typo here

> >+/* FP ABI requirement for ifunc with callback.  The new mode switch can only
> >+   be requested once.  */
> >+
> >+static int ifunc_fpabi = -1;
> >+
> 
> i think the resolver needs to be as-safe, so modified
> objects should be volatile (sig_atomic_t).
> 
We talked about this at cauldron. This is collorary of my question if
resolver is ok. We use recursive lock around that so I asked if its ok
when singal arrives while we hold it. Carlos said that we should check
all architectures if everything stays consistent. So ifunc should also
do same.

There is also question if we should resolve ifuncs early like with
LD_BIND_NOW=1. That we could already do eager binding implies that ifunc
should return same result while application runs.

> the ifunc situation is quite messy, is it supposed to be
> used outside of the libc? (i know on x86, gcc target libs
> and function multi-versioning use it, but i'd assume other
> targets would move away from it outside the libc).

Yes, its public but there isn't clear whats allowed and what isn't.


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