Make soft-fp symbols into compat symbols for powerpc*-*-linux*.
authorJoseph Myers <joseph@codesourcery.com>
Thu, 30 Oct 2014 17:28:30 +0000 (17:28 +0000)
committerJoseph Myers <jsm28@gcc.gnu.org>
Thu, 30 Oct 2014 17:28:30 +0000 (17:28 +0000)
commite610393ca76b204d861177a9ec542e2b4b3956cb
tree5cab873a18ab41830f86af14fc74a62d449e0851
parent2d51fcef56807789d5a6d929174a4581bd9e2ce3
Make soft-fp symbols into compat symbols for powerpc*-*-linux*.

Continuing preparations for implementing
TARGET_ATOMIC_ASSIGN_EXPAND_FENV for powerpc*-*-linux* soft-float and
e500, this patch makes soft-fp symbols used for those targets into
compat symbols when building with glibc >= 2.19, so that they are only
in shared libgcc for existing binaries requiring them, not in static
libgcc and not available for new links using shared libgcc.  Instead,
new links will get the symbols from libc, which has exported all of
them since 2.19.  (Actually all the symbols were exported from glibc
since 2.4, but some of them were exported by glibc as compat symbols
only - because of a confusion between deliberately present soft-fp
symbols and old accidental reexports of libgcc functions from glibc
2.0 - until 2.19.)

This allows user floating-point arithmetic to interoperate properly
with the state handled by <fenv.h> functions, whether software state
(for soft-float; TLS variables that don't form a public part of
glibc's ABI, so can only be accessed directly by functions within
glibc) or hardware state (for e500 - the copies of the soft-fp
functions in glibc being built to interoperate with the hardware state
whereas those in libgcc aren't).  Previously only glibc's own
functions, and those operations done in hardware on e500, properly
worked with that state, not direct floating-point arithmetic
operations that were implemented in software.

The intended next step is the actual TARGET_ATOMIC_ASSIGN_EXPAND_FENV
implementation.

The test of glibc >= 2.19 uses the same --with-glibc-version configure
option as in the gcc/ directory (but differently implemented; in gcc/
the fallback is to examine headers to find the version, while in
libgcc/ we can use compile for the target and so use AC_COMPUTE_INT).
The TARGET_ATOMIC_ASSIGN_EXPAND_FENV implementation will also only do
anything for glibc >= 2.19, as it will depend on generating calls to
functions __atomic_feholdexcept __atomic_feclearexcept
__atomic_feupdateenv that were added in 2.19 for that purpose (even
for e500, inline code is not readily possible because of the need to
make prctl syscalls from the implementation of these functions).

In order to make symbols compat symbols, the soft-fp files need
wrapping with generated wrappers including asm .symver directives,
which need to name the symbol version in question.  This is extracted
by an awk script from an intermediate stage of generating the .map
file for linking libgcc (that .map itself depends on the objects that
go into the library, so can't be used for this purpose as that would
mean a circular dependency); the extraction is not fully general
regarding the features available in .map generation, but suffices for
the present purpose.

It would make sense for hardfp.c symbols to be compat symbols as well
(in the cases where hardfp.c gets used, the functions in question
should not be used for new links), but this isn't required for the
present purpose, which is only concerned with ensuring that where
functions that should be affected by rounding modes or exceptions get
used, those functions are actually affected by those rounding modes or
exceptions.

Tested with no regressions with cross to powerpc-linux-gnu
(soft-float); c11-atomic-exec-5.c moves from UNSUPPORTED to FAIL, as
expected, now that floating-point arithmetic in user programs uses the
same state as <fenv.h> functions, so the fenv_exceptions test passes,
but TARGET_ATOMIC_ASSIGN_EXPAND_FENV isn't yet implemented.  (For
e500, c11-atomic-exec-5.c was already FAILing, as enough operations
worked with the hardware state for the fenv_exceptions effective
target test to pass.)  Also verified that the exported symbols and
versions are unchanged, with the expected symbols becoming compat
symbols at the same versions, and that with --with-glibc-version=2.18
the symbols remain normal rather than compat symbols.

* Makefile.in (libgcc.map.in): New target.
(libgcc.map): Use libgcc.map.in.
* config/t-softfp (softfp_compat): New variable to be set by
users.
[$(softfp_compat) = y] (softfp_map_dep, softfp_set_symver): New
variables.
[$(softfp_compat) = y] (softfp_file_list): Use files in the build
directory.
[$(softfp_compat) = y] ($(softfp_file_list)): Generate wrappers
that use compat symbols and disable all code unless [SHARED].
* config/t-softfp-compat: New file.
* find-symver.awk: New file.
* configure.ac (--with-glibc-version): New configure option.
(ppc_fp_compat): New variable set for powerpc*-*-linux*.
* configure: Regenerate.
* config.host (powerpc*-*-linux*): Use ${ppc_fp_compat} for
soft-float and e500.

From-SVN: r216942
libgcc/ChangeLog
libgcc/Makefile.in
libgcc/config.host
libgcc/config/t-softfp
libgcc/config/t-softfp-compat [new file with mode: 0644]
libgcc/configure
libgcc/configure.ac
libgcc/find-symver.awk [new file with mode: 0644]