This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: PATCH: Add ifunc attribute
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, gcc-patches at gcc dot gnu dot org, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 13 Jun 2009 17:15:00 +0200
- Subject: Re: PATCH: Add ifunc attribute
- References: <20090612154021.GA4317@lucon.org> <m3ljnwapj6.fsf@google.com>
On Sat, Jun 13, 2009 at 3:30 AM, Ian Lance Taylor<iant@google.com> wrote:
> "H.J. Lu" <hongjiu.lu@intel.com> writes:
>
>> +@item ifunc ("@var{function}")
>> +@cindex @code{ifunc} attribute
>> +The @code{ifunc} attribute only applies to global function definition,
>> +which causes the definition to be emitted as an indirec function. ?For
>> +instance,
>> +
>> +@smallexample
>> +void* f_ifunc () __attribute__ ((ifunc ("f")));
>> +@end smallexample
>> +
>> +defines @samp{f_ifunc} to be an indirect function for @samp{f}. This
>> +attribute is ignored if @samp{f_ifunc} is undefined in the same
>> +translation unit.
>> +
>> +See @code{STT_GNU_IFUNC} specified in @file{ifunc.txt} at
>> +@uref{http://groups.google.com/group/generic-abi/files}.
>> +
>> +Not all target machines support this attribute.
>
> This documentation needs to be much better. ?I think most people reading
> this would not understand the feature. ?I would suggest something more
> along these lines, but I would like to hear what other people think.
>
> I started to write my own version of the documentation, but I realized
> that I don't even understand this. ?Which function is called by the
> dynamic linker, "f" or "f_ifunc"? ?Why is the attribute ignored if
> "f_ifunc" is not defined; shouldn't it be an error? ?I guess that means
> that "f_ifunc" is called by the dynamic linker; in that case, what
> happens if "func" is defined?
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 ...
Richard.