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


Ondřej Bílka <neleai@seznam.cz>
> > 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.

I'm not sure I see any specific need for the outcome of an ifunc to be the
same when resolved early/late. Apart from the resolved function needing to
be at least usable I don't think there has to be any further requirements. 

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

Are you asking whether ifunc should be usable by an ordinary programmer in
their library? I'd say that it absolutely should be usable. We have some
syntactic sugar in GCC to simplify defining ifuncs and for those who do
then they need to follow a few rules about what can and cannot be done in
a resolver. You could go as far as to say that the idea proposed in this
patch could be the only way for an ifunc resolver to do anything other than
plain C code. i.e. no library calls allowed but some services are exposed
via a dynamic linker callback.

Thanks,
Matthew


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