This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Add ifunc attribute

On Sun, Jun 21, 2009 at 4:19 PM, H.J. Lu<> wrote:
> On Sun, Jun 21, 2009 at 2:23 AM, Jakub Jelinek<> wrote:
>> On Fri, Jun 19, 2009 at 03:00:04PM -0700, H.J. Lu wrote:
>>> > Yeah. ?I would have proposed that
>>> >
>>> > void *foo (void) __attribute__((__ifunc__))
>>> > {
>>> > ?return zero;
>>> > }
>>> >
>>> > would simply generate foo with indirect function type.
>>> >
>>> > This of course causes a problem if you have a declaration for
>>> > the real foo available - but then you should better not have that,
>>> > as the compiler will then derive wrong properties for the real foo
>>> > from the ifunc wrapper body.
>>> >
>>> > That would at least not introduce the confusion with the extra name ...
>>> >
>>> Here is the updated patch. I extended the ifunc attribute to
>>> static functions and added testcases to show that we need
>>> argument for ifunc attribute:
>> I agree with Richard here, ifunc attribute shouldn't have any arguments
>> and should just mean the function has gnu_indirect_function type instead
>> of function, nothing else. ?That way users can combine it with other
>> extensions to get the behavior they want, rather than having weird
>> unexpected effects (in your case foo_ifunc is for some surprisingly
>> not defined at all).
>> If you don't have foo's prorotype in the current translation unit, you can
>> just use ifunc attribute alone, if you do have the prototype, it is not
>> much harder, e.g.
>> __typeof (foo) *foo_ifunc (void) __asm ("foo") __attribute__((ifunc))
>> {
>> ?return foo_impl1;
>> }
>> will work just fine. ?In this case you don't need to teach GCC about special
>> properties of ifunc attribute, foo for GCC isn't defined in the current
>> translation unit (it doesn't look at DECL_ASSEMBLER_NAME for inlining and
>> similar purposes).
> Using
> static __typeof (foo) *foo_ifunc (void) __asm ("foo") __attribute__((ifunc))
> is not much better than
> static __typeof (foo) * foo_ifunc (void) __asm__ ("foo");
> __asm__(".type foo, %gnu_indirect_function");

Does that work reliably without -fno-toplevel-reorder?  Where is  your
implementation of foo_ifunc in this case?  A trivial example yields

        .type foo, %gnu_indirect_function
        .p2align 4,,15
        .type   foo, @function
        pushl   %ebp

I wonder if that would be well-defined.

> Also, I am getting
> ifunc-2.c:3:12: warning: 'foo' used but never defined
> on static ifunc. ?It is not a new problem:
> [hjl@gnu-6 tmp]$ cat foo.c
> static int foo ();
> static int foo_ifunc (void) __asm__ ("foo");
> static int
> foo_ifunc (void)
> {
> ?return 0;
> }
> int
> bar ()
> {
> ?return foo ();
> }
> [hjl@gnu-6 tmp]$ gcc foo.c -S
> foo.c:1: warning: âfooâ used but never defined
> [hjl@gnu-6 tmp]$
> How can we solve this?

By not declaring foo static.  It would be wrong to do so, as it
doesn't really bind locally and gcc would not be allowed to
do optimizations on it that it could do with a locally binding


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]