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

Szabolcs Nagy szabolcs.nagy@arm.com
Mon Sep 14 16:40:00 GMT 2015


On 14/09/15 15:33, Matthew Fortune wrote:
> Ondřej Bílka <neleai@seznam.cz>
>>> 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

yes

> 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

i think the rules currently depend on dynamic
linker internals and are target specific.
(which is ok if ifunc is only used in the libc
but not ok if users write ifunc resolvers).

e.g. i don't see the fp registers saved/restored
in mips _dl_runtime_resolve, so the ifunc resolver
must not clobber fp (argument) regs.
(on x86 an ifunc resolver can clobber fp regs.)

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

if no library calls are allowed from a resolver
then the ifunc dispatch mechanism is limited,
if some libc calls are allowed then those should
be documented.

(some libc calls may be generated by the compiler
e.g. memcpy)

> Thanks,
> Matthew
>



More information about the Libc-alpha mailing list