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

[Stefan Liebler]

On 08/09/2016 01:56 PM, Florian Weimer wrote:
> 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.
Here are some information so far:
In <gcc-src>/gcc/config.gcc IFUNC-support is only enabled by default for 
intel and s390 targets. See the following commits:
-"Don't enable IFUNC by default for Android and uclibc"
2014-11-14 precedes gcc-5_1_0-release
(https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e6cdd6b1755033e8f416efaa4334d1294c0a43c6)
Don't set default_gnu_indirect_function variable=yes for targets 
*-*-*android*|*-*-*uclibc*.

-"* config.gcc: Enable ifunc attribute by default on s390 and s390x."
2012-07-05 precedes gcc-4_8_0-release, gcc-4_9_0-release, gcc-5_1_0-release
(https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fcddec9f2159d14c98924e4ccd2dabffa6bd4a0e)
default_gnu_indirect_function=yes for targets s390x-*-linux* and 
s390-*-linux*.

-"* config.gcc (i[34567]86-*-linux*): Set default_gnu_indirect_function 
to yes."
2011-07-22 precedes alpha-v0.1, gcc-4_7_0-release, gcc-4_8_0-release, 
gcc-4_9_0-release, gcc-5_1_0-release
(https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2c6c4996dd9e4b6cc96639b270954405c79f648d)
default_gnu_indirect_function=yes for targets x86_64-*-linux*

-"* configure.ac: Add --enable-indirect-function option."
2010-09-29 precedes alpha-v0.1, gcc-4_6_0-release, gcc-4_7_0-release, 
gcc-4_8_0-release, gcc-4_9_0-release, gcc-5_1_0-release
(https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1c6e0788f1a7e6b577c101d5c3ee9a8cb01ac4d5)
default_gnu_indirect_function=yes for targets i[34567]86-*-linux*
and default_gnu_indirect_function=glibc-2011 for targets x86_64-*-linux*

Each distro can activate gcc ifunc support with gcc configure option 
--enable-gnu-indirect-function.
According to the gcc.specs file from fedora 21 gcc-4.9.2-1.fc21.src.rpm 
this is done for fedora >= 21 and rhel >= 7:
%ifarch %{ix86} x86_64 ppc ppc64 ppc64le ppc64p7 s390 s390x %{arm} aarch64
%global attr_ifunc 1
%else
%global attr_ifunc 0
%endif

%if 0%{?fedora} >= 21 || 0%{?rhel} >= 7
%if %{attr_ifunc}
	--enable-gnu-indirect-function \
%endif
%endif


The debian/ubuntu/opensuse gcc source packages rely on the default 
behaviour and don't use --enable-gnu-indirect-function.
>
> 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).
One way is to rely on the distro maintainers which picks up the glibc 
release with this patchset that they also use a gcc with ifunc support.

I think the better approach is the previous way to test gcc ifunc 
support and use it if available and provide the old behaviour as 
fallback (see the former version of the patchset). This way we don't 
break an architecture which is currently using binutils-only-ifunc support.
Afterwards we can add a NEWS entry, update the recommended gcc in 
INSTALL, send a note to the distribution maintainers.
Perhaps more gccs support ifunc in the future and we can remove the 
fallback.
>
>> 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
>