On Thu, Oct 30, 2014 at 11:13 AM, Joseph S. Myers
<jos...@codesourcery.com> wrote:
> 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. OK to commit?
>
> 2014-10-30 Joseph Myers <jos...@codesourcery.com>
>
> * 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.
Okay.
Thanks, David
