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

[Szabolcs Nagy]

On 03/09/15 23:03, Faraz Shahbazker wrote:
> Comments are invited on the prototype of the IFUNC resolver for MIPS. We want
> something flexible enough to handle current requirements and extensions.
>
> This patch, from RobertS, provides the resolver with 2 HWCAP registers and a
> callback control function. The callback currently provides the ability to
> toggle/switch between FP ABI modes.
...
> @@ -43,7 +44,9 @@ elf_ifunc_invoke (ElfW(Addr) addr)
>                               (unsigned long int)t_addr);
>       }
>
> -  return ((ElfW(Addr) (*) (unsigned long int)) (addr)) (GLRO(dl_hwcap));
> +  return ((ElfW(Addr) (*) (unsigned long int, unsigned long int,
> +                          int (int, int))) addr)
> +    (GLRO(dl_hwcap), GLRO(dl_hwcap2), dl_ifunc_control);
>   }
>

the only ifunc documentation i know of says

"The calling convention of the STT_GNU_IFUNC function, which takes
no arguments and returns a function pointer, should follow the
processor-specific ABI."
(ifunc.txt at https://sites.google.com/site/x32abi/documents )

this is for x86 and wrong for other archs.

i think the interface contracts of the resolver should be
documented if ifunc is used outside the libc.

 > +static int __attribute_used__
 > +dl_ifunc_control (int operation, int value)
 > +{
...
 > +          /* Remember the choice for the last compabitle FP ABI.  */
 > +          ifunc_fpabi = in_abi;
...
> +/* 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).

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