about summary refs log tree commit diff
path: root/lib
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2013-08-16 17:09:07 -0400
committerRich Felker <dalias@aerifal.cx>2013-08-16 17:09:07 -0400
commit4918c2bb206bfaaf5a1f7d3448c2f63d5e2b7d56 (patch)
treef75c8190d06f3dbcac157bfcd3ec0db99c32f23c /lib
parent7318c62e6439fca75ca3d50ddf0bd81a151c2766 (diff)
downloadmusl-4918c2bb206bfaaf5a1f7d3448c2f63d5e2b7d56.tar.gz
musl-4918c2bb206bfaaf5a1f7d3448c2f63d5e2b7d56.tar.xz
musl-4918c2bb206bfaaf5a1f7d3448c2f63d5e2b7d56.zip
fix detection of arm hardfloat
it turns out that __SOFTFP__ does not indicate the ABI in use but
rather that fpu instructions are not to be used at all. this is
specified in ARM's documentation so I'm unclear on how I previously
got the wrong idea. unfortunately, this resulted in the 0.9.12 release
producing a dynamic linker with the wrong name. fortunately, there do
not yet seem to be any public toolchain builds using the wrong name.

the __ARM_PCS_VFP macro does not seem to be official from ARM, and in
fact it was missing from the very earliest gcc versions (around 4.5.x)
that added -mfloat-abi=hard. it would be possible on such versions to
perform some ugly linker-based tests instead in hopes that the linker
will reject ABI-mismatching object files, if there is demand for
supporting such versions. I would probably prefer to document which
versions are broken and warn users to manually add -D__ARM_PCS_VFP if
using such a version.

there's definitely an argument to be made that the fenv macros should
be exposed even in -mfloat-abi=softfp mode. for now, I have chosen not
to expose them in this case, since the math library will not
necessarily have the capability to raise exceptions (it depends on the
CFLAGS used to compile it), and since exceptions are officially
excluded from the ARM EABI, which the plain "arm" arch aims to
follow.
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions