https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77894

            Bug ID: 77894
           Summary: Enable GNU indirect function support by default as it
                    will be used in glibc.
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: stli at linux dot vnet.ibm.com
  Target Milestone: ---

Starting with glibc-commits "Add configure check to test if gcc supports
attribute ifunc."
(https://sourceware.org/git/?p=glibc.git;a=commit;h=022dfdce000374b60aadfb0a5ed9a5c4c1dbd29b),
"Use gcc attribute ifunc in libc_ifunc macro instead of inline assembly due to
false... "
(https://sourceware.org/git/?p=glibc.git;a=commit;h=00980d845f8f2ec3ed4ad161a1e5b97704be1929)
and further, for glibc with multi-arch support it is recommended to use a GCC
which has been built with support for GNU indirect functions. This ensures that
correct debugging information is generated for functions selected by IFUNC
resolvers. This support can either be enabled by configuring GCC with
'--enable-gnu-indirect-function', or by enabling it by default by setting
'default_gnu_indirect_function' variable for a particular architecture in the
GCC source file 'gcc/config.gcc'.

Currently GNU indirect function support is only enabled by default for few
configurations like intel and s390. Please enable it by default for other
architectures, too. E.g. according to the rpm-spec file fedora/rhel is
configuring gcc with --enable-gnu-indirect-function for the following
architectures: %{ix86} x86_64 ppc ppc64 ppc64le ppc64p7 s390 s390x %{arm}
aarch64.

Perhaps a configure check could test the presence of the non-standard gnu ifunc
support in the assembler, linker and dynamic linker and could automatically
dis/enable the support. But this behaviour should be discussed by the gcc
maintainers.

Reply via email to