[Top] [All Lists]

Re: [IFUNC] PATCH: Add an ifunc attribute

Subject: Re: [IFUNC] PATCH: Add an ifunc attribute
From: Alan Modra
Date: Thu, 23 Jul 2009 12:20:41 +0930
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

Proponents of ifunc support in gcc may say that the powerpc backend
ought to be taught how to provide "&one" without using the GOT.  I say
that's an unacceptable burden on target maintainers.  These foo_ifunc
style functions are likely to be only used in glibc, and implemented
in assembly anyway for speed.

Alan Modra
Australia Development Lab, IBM

<Prev in Thread] Current Thread [Next in Thread>