Re: [RFC 2/2] Update prototype of IFUNC resolver for MIPS

[OndÅej BÃlka <neleai at seznam dot cz>]

On Mon, Sep 14, 2015 at 02:33:47PM +0000, Matthew Fortune wrote:
> 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. 
>
While not I am saying that user shouldn't rely that ifunc would be
resolved late. 
 
> > > 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 am not saying that, I am saying that currently one frequently finds
situations where it isnt clear if its user fault or our. For example I
wrote sample ifunc for shared library, it got seqfault and it turned out
it was because function that I returned was public and not resolved yet.

> 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.
>
I would disagree with that for two reason, first is that no library
calls limit usability. If one wants to select function based on profile
data he needs to mmap file with data or so.

Second is that ifunc should be implementation detail rather than
interface. I have on my todo list to add multiple cpu dispatch for gcc
and there are several ways to do it. I would like more fat binaries as
there is problem that to inline ifunc you need to also turn callers into
ifunc so gcc would need to understand resolver.

Other alternative that uses ifunc would add gcc attribute that tells gcc
to make variants of function for each arch, that could be now done with
macro that defines resolver, for variants uses __attribute__((target("foo"))) 
and always inline original function.