This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |