Re: PATCH: Add ifunc attribute

[Richard Guenther <richard dot guenther at gmail dot com>]

On Sun, Jun 21, 2009 at 6:41 PM, H.J. Lu<hjl.tools@gmail.com> wrote:
> On Sun, Jun 21, 2009 at 8:34 AM, Richard
> Guenther<richard.guenther@gmail.com> wrote:
>> On Sun, Jun 21, 2009 at 4:19 PM, H.J. Lu<hjl.tools@gmail.com> wrote:
>>> On Sun, Jun 21, 2009 at 2:23 AM, Jakub Jelinek<jakub@redhat.com> 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
>>
>> #APP
>> ? ? ? ?.type foo, %gnu_indirect_function
>> #NO_APP
>> ? ? ? ?.text
>> ? ? ? ?.p2align 4,,15
>> ? ? ? ?.type ? foo, @function
>> foo:
>> ? ? ? ?pushl ? %ebp
>> ...
>>
>> I wonder if that would be well-defined.
>
> I got
>
> [hjl@gnu-6 gcc]$ cat /tmp/i.c
> static int
> zero (int x)
> {
> ?return 0;
> }
>
> static void * foo_ifunc (void) __asm__ ("foo") __attribute__ ((used));
> static void * foo_ifunc (void) { return zero ; }
> __asm__(".type foo, %gnu_indirect_function");
> [hjl@gnu-6 gcc]$ gcc -O2 -S /tmp/i.c -ftoplevel-reorder
> [hjl@gnu-6 gcc]$ cat i.s
> ? ? ? ?.file ? "i.c"
> #APP
> ? ? ? ?.type foo, %gnu_indirect_function
> #NO_APP
> ? ? ? ?.text
> ? ? ? ?.p2align 4,,15
> ? ? ? ?.type ? zero, @function
> zero:
> .LFB2:
> ? ? ? ?xorl ? ?%eax, %eax
> ? ? ? ?ret
> .LFE2:
> ? ? ? ?.size ? zero, .-zero
> ? ? ? ?.p2align 4,,15
> ? ? ? ?.type ? foo, @function
> foo:
> .LFB3:
> ? ? ? ?movl ? ?$zero, %eax
> ? ? ? ?ret
> .LFE3:
> ? ? ? ?.size ? foo, .-foo
>
> I don't see why it should be a problem.

Because there are two .type for foo.  If you say that is well-defined, ok ...

>>> 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
>> function.
>>
>
> I added static ifunc support to binutils under request from Jakub.
> I am enclosing my current gcc patch, which handles static ifunc
> correctly. With static ifunc, you can have 2 ifunc foo in 2 different
> files in a library and you don't have to worry if someone else
> defines a normal global foo for total different purpose, which
> may override your foo.

Ok, so for the static case we could either overload the used or
unused attributes or invent a new defined attribute:

static int foo () __attribute__((defined));

that would also solve the general case with asm renaming.  Or
simply recognize the asm name as something that is defined
properly.

Richard.

> Thanks.
>
> --
> H.J.
>