gcc/libgcc/find-symver.awk

29 lines
847 B
Awk
Raw Normal View History

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
2014-10-30 18:28:30 +01:00
# Extract the version of a single symbol from the version map.
# Copyright (C) 2014-2017 Free Software Foundation, Inc.
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
2014-10-30 18:28:30 +01:00
#
# This file is part of GCC.
#
# GCC is free software; you can redistribute it and/or modify it under
# the terms of the GNU General Public License as published by the Free
# Software Foundation; either version 3, or (at your option) any later
# version.
#
# GCC is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GCC; see the file COPYING3. If not see
# <http://www.gnu.org/licenses/>.
/^[A-Z]/ {
version = $1;
next;
}
$1 == symbol {
print version
exit
}