How to (cross-)compile to both ARM hard- and soft-float (softfp) with a single GCC (cross-)compiler?
Asked Answered
C

2

7

I'd like to use a single (cross-)compiler to compile code for different ARM calling conventions: since I always want to use floating point and NEON instructions, I just want to select the hard-float calling convention or the soft-float (softfp) calling convention.

My compiler defaults to hard-float, but it supports both architectures that I need:

$ arm-linux-gnueabihf-gcc -print-multi-lib
.;
arm-linux-gnueabi;@marm@march=armv4t@mfloat-abi=soft
$

When I compile with the default parameters:

$ arm-linux-gnueabihf-g++ -Wall -o hello_world_armhf hello_world.cpp

It succeeds without any errors.

If I compile with the parameters returned by -print-multi-lib:

$ arm-linux-gnueabihf-g++ -marm -march=armv4t -mfloat-abi=soft -Wall -o hello_world hello_world.cpp

It again compiles without error (By the way, how can I test that the resultant code is hard- or soft-float?)

Unfortunately, if I try this:

$ arm-linux-gnueabihf-g++ -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -Wall -o hello_world hello_world.cpp
[...]/gcc/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld: error: hello_world uses VFP register arguments, /tmp/ccwvfDJo.o does not
[...]/gcc/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld: failed to merge target specific data of file /tmp/ccwvfDJo.o
collect2: error: ld returned 1 exit status
$

I've tested some other permutations of the parameters, but it seems that anything other than the combination shown by -print-multi-lib results in an error.

I've read ARM compilation error, VFP registered used by executable, not object file but the problem there was that some parts of the binary were soft- and some were hard-float. I have a single C++ file to compile...

What parameter(s) I miss to be able to compile with -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon?

How is it possible that the error is about VFP register arguments while I explicitly have -mfloat-abi=softfp in the command line which prohibits VFP register arguments?

Thanks!

For the records, hello_world.cpp contains the following:

#include <iostream>

int main()
{
  std::cout << "Hello, world!" << std::endl;
  return 0;
}
Cobos answered 21/3, 2014 at 14:45 Comment(4)
You still have the same issue as the other question - parts of your binary (your code) is soft-float, other parts (the staticly-linked bits of the standard library) are hard-float because you haven't passed the combination of options that multilib is looking for. I don't know enough to give a proper answer, but I suspect it involves recompiling GCC with your desired multilib options.Poultryman
I think a single source file compilation with g++ shall not end up in error messages, no matter what arguments I pass to the compuler. If it it linking with incompatible libc, libgcc, whatever, it is a compiler bug isn't it? Note that the linker is invoked by the compiler, so theoretically it could pass the proper arguments to the linker based on the compiler parameters. Do you know how to affect multilib to switch architecture/calling convention? It would be great to switch it to arm-linux-gnueabi then add my compiler options.Approximal
Step one: build Clang. Step two: use -target compiler option. ;). (And don't forget step 2.5: make Clagn find everything for you configuration)Ec
Possible duplicate of ARM compilation error, VFP registered used by executable, not object fileFrown
B
1

You need another compiler with corresponding multilib support. You can check multilib support with next command.

arm-none-eabi-gcc -print-multi-lib
.;
thumb;@mthumb
fpu;@mfloat-abi=hard
armv6-m;@mthumb@march=armv6s-m
armv7-m;@mthumb@march=armv7-m
armv7e-m;@mthumb@march=armv7e-m
armv7-ar/thumb;@mthumb@march=armv7
cortex-m7;@mthumb@mcpu=cortex-m7
armv7e-m/softfp;@mthumb@march=armv7e-m@mfloat-abi=softfp@mfpu=fpv4-sp-d16
armv7e-m/fpu;@mthumb@march=armv7e-m@mfloat-abi=hard@mfpu=fpv4-sp-d16
armv7-ar/thumb/softfp;@mthumb@march=armv7@mfloat-abi=softfp@mfpu=vfpv3-d16
armv7-ar/thumb/fpu;@mthumb@march=armv7@mfloat-abi=hard@mfpu=vfpv3-d16
cortex-m7/softfp/fpv5-sp-d16;@mthumb@mcpu=cortex-m7@mfloat-abi=softfp@mfpu=fpv5-sp-d16
cortex-m7/softfp/fpv5-d16;@mthumb@mcpu=cortex-m7@mfloat-abi=softfp@mfpu=fpv5-d16
cortex-m7/fpu/fpv5-sp-d16;@mthumb@mcpu=cortex-m7@mfloat-abi=hard@mfpu=fpv5-sp-d16
cortex-m7/fpu/fpv5-d16;@mthumb@mcpu=cortex-m7@mfloat-abi=hard@mfpu=fpv5-d16
https://mcmap.net/q/1628909/-how-to-interpret-the-output-of-gcc-print-multi-lib

How to interpret the output of gcc -print-multi-lib With this configuration gcc -mfloat-abi=hard not only will build your files using FPU instructions but also link them with corresponding libs, avoiding "X uses VFP register arguments, Y does not" error.

The above-mentioned -print-multi-lib output produced by gcc with this patch and --with-multilib-list=armv6-m,armv7,armv7-m,armv7e-m,armv7-r,armv7-a,cortex-m7 configuration option. If you are interested in building your own gcc with Cortex-A series multilib support, just use --with-multilib-list=aprofile configuration option for any arm*-*-* target without any patches (at list with gcc-6.2.0).

Bloom answered 3/11, 2016 at 23:44 Comment(0)
S
0

As per Linaro FAQ if your compiler prints arm-linux-gnueabi;@marm@march=armv4t@mfloat-abi=soft then you can only use -march=armv4t. If you want to use -march=armv7-a you need to build compiler yourself.

Following link could be helpful in building yourself GCC ARM Builds

Sync answered 29/5, 2014 at 14:24 Comment(2)
Are these ARM architectures so different that they can not be supported by a single toolchain? I thought that these are "just" instruction set / optimization / calling convention settings just like we have on x86...Approximal
The biggest problems is standard libraries that are included in your toolchain. Unless toolchain vendor deliberately included multilib support, you only have libs compiled for a particular core and linker would refuse to mix them with code compiled for incompatible core (as this is doomed to fail at runtime anyway).Reparative

© 2022 - 2024 — McMap. All rights reserved.