This is the mail archive of the
mailing list for the libc-ports project.
Re: fixing ARM aeabi fesetround and friends
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Adam Goode <adam at spicenitz dot org>
- Cc: libc-ports at sources dot redhat dot com
- Date: Sat, 18 Apr 2009 09:55:13 +0000 (UTC)
- Subject: Re: fixing ARM aeabi fesetround and friends
- References: <49E93679.email@example.com>
On Fri, 17 Apr 2009, Adam Goode wrote:
> Can we change the dl_hwcap conditional there to read the VFP attribute
> tag instead? Is this information still around at the point fesetround is
> called? I am trying to figure out how to load this information, it looks
> like something in dl-sysdep, but I'm not sure. Any hints are welcome.
I think the information will be merged by the linker to record that VFP is
used by the final program if any object file uses it, which is not what
you want here (you want to know whether any object file uses soft float -
and you don't care about assembly files not using floating point at all
...), and the information only goes in the static linker view of the final
program, not the dynamic linker view, so isn't going to be readily
Arguably, you should only care anyway if some object uses software
floating point *and* was compiled with -frounding-math (or with the
FENV_ACCESS pragma, but that isn't implemented yet), and maybe the
compiler should warn if you request -frounding-math for anything using
software floating point that doesn't support rounding modes. If you don't
use -frounding-math (or the pragma) you are guaranteeing that code in the
object will only ever execute with the default rounding mode.
One approach would be for the __aeabi_* software floating-point functions
to use VFP is VFP is available at runtime, so that binaries built for
software floating point will use the VFP instructions if available (slower
than building them for VFP directly, faster than them using software).
Since the information about availability of VFP isn't readily available in
libgcc, one possibility might be:
* Make libgcc define the functions to use VFP if libgcc is built for VFP
(defined (__VFP_FP__) && !defined (__SOFTFP__)).
* Build both VFP and soft-float copies of libgcc by using an appropriate
compiler multilib configuration.
* Add HWCAP_ARM_VFP to HWCAP_IMPORTANT, so that a copy of the shared
libgcc in /lib/vfp will be found at runtime by the dynamic linker.
* Arrange for the compiler to link with the shared libgcc by default so
that the __aeabi_* functions come from shared libgcc and so can be
replaced at dynamic link time.
But then you have dynamic linking overhead for calls to these functions,
which isn't needed for most cases. There is no perfect solution; the
present code tries to help programs built for VFP without needing a
separate VFP libc, at the expense of not telling programs using the
unsupported soft-float plus rounding modes or exceptions combination that
it is unsupported at runtime. (See my suggestion above that the compiler
should warn about this at compile time.) C99 doesn't allow for all the
combinations you can get for some targets of IEEE rounding modes and
exceptions being supported for some types or under some conditions but not
Joseph S. Myers