Re: PATCH: Add ifunc attribute

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

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.

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

Thanks.

-- 
H.J.

Attachment: gcc-ifunc-6.patch
Description: Text document