arm softfp compatibility arch/fpu in gcc-4.8.2

arm softfp compatibility arch/fpu in gcc-4.8.2

[David Wuertele]

Just starting with musl, http://wiki.musl-libc.org/wiki/Getting_started said
for my Tegra 3 to use

--with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16

This works fine except for one thing -- I have some libraries built with a
soft-float toolchain that I need to link against.  The VFP register seems to be
the problem:

arm-linux-musleabihf/4.8.2/../../../../arm-linux-musleabihf/bin/ld: error: sign
uses VFP register arguments, lib/armeabi/libXXX.a(YYY.o) does not
arm-linux-musleabihf/4.8.2/../../../../arm-linux-musleabihf/bin/ld: failed to
merge target specific data of file lib/armeabi/libXXX.a(YYY.o)

What arch/fpu should I use to build a toolchain that can link against this
library?

Thanks,
Dave

Re: arm softfp compatibility arch/fpu in gcc-4.8.2

[John Spencer]

David Wuertele wrote:
> Just starting with musl, http://wiki.musl-libc.org/wiki/Getting_started said
> for my Tegra 3 to use
> 
> --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16
> 
> This works fine except for one thing -- I have some libraries built with a
> soft-float toolchain that I need to link against.  The VFP register seems to be
> the problem:
> 
> arm-linux-musleabihf/4.8.2/../../../../arm-linux-musleabihf/bin/ld: error: sign
> uses VFP register arguments, lib/armeabi/libXXX.a(YYY.o) does not

"does not" is not really a helpful error message.

> arm-linux-musleabihf/4.8.2/../../../../arm-linux-musleabihf/bin/ld: failed to
> merge target specific data of file lib/armeabi/libXXX.a(YYY.o)
> 
> What arch/fpu should I use to build a toolchain that can link against this
> library?

if you need to link to proprietary softfloat modules, you have to use 
"softfp" float mode. that one is compatible to soft, but makes full use 
of the FPU.

Re: arm softfp compatibility arch/fpu in gcc-4.8.2

[Rich Felker]

On Thu, Nov 07, 2013 at 11:21:33PM +0100, John Spencer wrote:
> >arm-linux-musleabihf/4.8.2/../../../../arm-linux-musleabihf/bin/ld: failed to
> >merge target specific data of file lib/armeabi/libXXX.a(YYY.o)
> >
> >What arch/fpu should I use to build a toolchain that can link against this
> >library?
> 
> if you need to link to proprietary softfloat modules, you have to
> use "softfp" float mode. that one is compatible to soft, but makes
> full use of the FPU.

Yes, the basic issue is that these modules are compiled for the
standard ARM EABI, not the VFP hard-float ABI variant. It's possible
to have both installed in parallel, but if you'll be working with
straight EABI library code, I would just use the "softfp" mode (which
yields ld-musl-arm.so.1 rather than ld-musl-armhf.so.1) for everything
for the sake of simplicity (so that you only have to have one set of
libraries).

I think this issue should be made more clear on the wiki: that there
is a choice between two different ARM ABIs here, and that the choice
of which is appropriate depends on both where you want your code to
run and what existing binary code you might be linking with it.

Rich

Re: arm softfp compatibility arch/fpu in gcc-4.8.2

[David Wuertele]

John Spencer <maillist-musl <at> barfooze.de> writes:

> > arm-linux-musleabihf/4.8.2/../../../../arm-linux-musleabihf/bin/ld: failed to
> > merge target specific data of file lib/armeabi/libXXX.a(YYY.o)
> > 
> > What arch/fpu should I use to build a toolchain that can link against this
> > library?
> 
> if you need to link to proprietary softfloat modules, you have to use 
> "softfp" float mode. that one is compatible to soft, but makes full use 
> of the FPU.

Thanks!  That was what I was hoping.

I see that gcc-4.8.2 supports "--with-float=softfp".  I'm confused about what
to use for "--with-fpu", if anything.  My choices are:

		| vfp | vfp3 | vfpv3 \
		| vfpv3-fp16 | vfpv3-d16 | vfpv3-d16-fp16 | vfpv3xd \
		| vfpv3xd-fp16 | neon | neon-fp16 | vfpv4 | vfpv4-d16 \
		| fpv4-sp-d16 | neon-vfpv4 | fp-arm-v8 | neon-fp-armv8 \
                | crypto-neon-fp-armv8)

If I omit the "--with-fpu", will it just default to use soft float all the time?

Dave

Re: Re: arm softfp compatibility arch/fpu in gcc-4.8.2

[John Spencer]

David Wuertele wrote:
> John Spencer <maillist-musl <at> barfooze.de> writes:
> 
>>> arm-linux-musleabihf/4.8.2/../../../../arm-linux-musleabihf/bin/ld: failed to
>>> merge target specific data of file lib/armeabi/libXXX.a(YYY.o)
>>>
>>> What arch/fpu should I use to build a toolchain that can link against this
>>> library?
>> if you need to link to proprietary softfloat modules, you have to use 
>> "softfp" float mode. that one is compatible to soft, but makes full use 
>> of the FPU.
> 
> Thanks!  That was what I was hoping.
> 
> I see that gcc-4.8.2 supports "--with-float=softfp".  I'm confused about what
> to use for "--with-fpu", if anything.  My choices are:
> 
> 		| vfp | vfp3 | vfpv3 \
> 		| vfpv3-fp16 | vfpv3-d16 | vfpv3-d16-fp16 | vfpv3xd \
> 		| vfpv3xd-fp16 | neon | neon-fp16 | vfpv4 | vfpv4-d16 \
> 		| fpv4-sp-d16 | neon-vfpv4 | fp-arm-v8 | neon-fp-armv8 \
>                 | crypto-neon-fp-armv8)
> 
> If I omit the "--with-fpu", will it just default to use soft float all the time?

not sure what the default is, but afaik vfp is the most compatible one 
(only needed when you want to create binaries that work on way less 
decent arm chips).
if you want the best speed, pick one of the neons - not sure which one 
your chip supports though. cortex A8 already supports neon, so that one 
should definitely work for you while giving decent performance.
in doubt, ask your vendor for the best setting.

Re: Re: arm softfp compatibility arch/fpu in gcc-4.8.2

[Rich Felker]

On Thu, Nov 07, 2013 at 11:46:26PM +0100, John Spencer wrote:
> >If I omit the "--with-fpu", will it just default to use soft float all the time?
> 
> not sure what the default is, but afaik vfp is the most compatible
> one (only needed when you want to create binaries that work on way
> less decent arm chips).

VFP is the only one which gives IEEE conforming behavior and the only
one which is explicitly supported by musl (which requires/provides
IEEE floating point semantics). Anything else might blow up (for
example, crashing or wrong results in strtod or printf) so I would not
recommend using them for compiling musl. If you want to use them in
application code linked to musl (with the standard EABI, i.e. "arm")
that doesn't depend on IEEE semantics, that shouldn't hurt anything.

Fortunately, at least as I understand it, the other ARM fpu options
were never widely available, and are pretty much deprecated.

Rich