Re: [IFUNC] PATCH: Add an ifunc attribute

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Jul 22, 2009 at 7:50 PM, Alan Modra<amodra@bigpond.net.au> wrote:
> On Thu, Jul 02, 2009 at 12:49:00PM -0700, Mark Mitchell wrote:
>> Richard Henderson wrote:
>>
>> > The suggestion I had been about to post was
>> >
>> > ? mangle_type(foo, typename)
>> > ? mangle_type("bar", typename)
>>
>> > The idea being the string/identifier would be used as the base
>> > name of the function, with the rest of the goop coming from the
>> > given type. ?One could then create mangled names that don't
>> > correspond to any function declaration in scope.
>>
>> That's probably not going to work in full generality. ?For example, the
>> identifier might S<double>::T<int>::foo, and mangling all of that is
>> going to be hard without actually being able to find The Declaration. ?I
>> think that life will be a lot easier if we require the declaration to be
>> in scope (it can be just an extern declaration of a function never
>> actually defined), and then have a syntax that allows us to refer to it
>> (either by spelling out the declaration, or via the cast syntax, which
>> is then a valid C++ expression).
>
> Having looked at STT_GNU_IFUNC for powerpc, I think that specialised
> ifunc support does not belong in the compiler *at all*. ?The reason is
> simple: ?You can't write STT_GNU_IFUNC functions in C, let alone in
> C++, and expect them to work on more than x86 or x86_64. ?Consider
> this testcase from glibc/elf/ifuncmain6pie.c
>
> static int
> one (void)
> {
> ?return -30;
> }
>
> void * foo_ifunc (void) __asm__ ("foo");
> __asm__(".type foo, %gnu_indirect_function");
>
> void *
> foo_ifunc (void)
> {
> ?return one;
> }
>
> You can hardly have a simpler foo_ifunc, but even this won't work on
> targets that implement PIC by using a GOT entry for the address of
> "one". ?The problem is that foo_ifunc is called when the dynamic
> loader is relocating the object; ?The GOT entry for "&one" may or may
> not be relocated before foo_ifunc is called. ?You can arrange for
> dynamic relocations within one object to be ordered correctly, but
> this doesn't help when there are function pointer initialisations from
> another dynamic object. ?The object with the pointer may be relocated
> before the one with foo_ifunc, so call foo_ifunc with an unrelocated
> GOT.
>

There are some limitations on STT_GNU_IFUNC functions:

1. Use other global data/function which may need relocations first.
2. Call other global functions.

You just have to avoid those cases.

-- 
H.J.