This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 1/9] Add configure check to test if gcc supports attribute ifunc.
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