Re: [PATCH v2 1/9] Add configure check to test if gcc supports attribute ifunc.

[Florian Weimer <fweimer at redhat dot com>]

On 08/08/2016 06:40 PM, Joseph Myers wrote:
> On Mon, 8 Aug 2016, Stefan Liebler wrote:
>
> > This patch adds a configure check to test if gcc supports attribute ifunc.
> > The support can either be enabled in <gcc-src>/gcc/config.gcc for one
> > architecture in general by setting default_gnu_indirect_function variable to yes
> > or by configuring gcc with --enable-gnu-indirect-function.
> >
> > The next patch rewrites libc_ifunc macro to use gcc attribute ifunc instead
> > of inline assembly to generate the IFUNC symbols due to false debuginfo.
> >
> > If gcc does not support attribute ifunc and glibc is configured with
> > --enable-multi-arch then configure will abort with an error message.
> > If --enable-multi-arch is not given then configure will silently
> > disable multi-arch support.
>
> I'm concerned about requiring non-default configure options.  Various
> architectures support IFUNC in binutils and may have done so for a long
> time, but without the option being enabled in GCC by default.  There
> should be a much more detailed analysis of which architectures have IFUNC
> support in binutils, when it was added, and correspondingly, whether it's
> enabled by default in GCC for those architectures and, if so, when such
> enabling was added.

Is this really necessary?  Can't we rely on architecture maintainers to 
do this?

Moving from assembler hacks to a cleaner, GCC-provided interface is a 
desirable cleanup.  Stefan took up this work because we ask him to, and 
now his little project went sideways *again*.  This doesn't look fair to 
me.  We should probably go back to Stefan's original approach (sorry, 
Stefan).

> In any case, new compiler requirements must be documented in install.texi
> with INSTALL regenerated.  And should have appropriate NEWS entries as
> well.

Agreed on this part.

Thanks,
Florian