Are there any technical limitations when running hard-float binaries on a soft-float OS?

Question

Since the hardware is generally the same between Raspberry Pi's, the target hardware is known to have a hardware floating point unit. I also understand that some operating systems opt to use soft-FP based instructions over using the FPU for software compatibility reasons.

However, I'm wondering: what's stopping you from using the ARM opcodes to use the FPU, even under a soft-FP compiled OS? Are there any technical limitations to running hard-FP binaries on a soft-FP operating system?

Finally, given the above two questions, can I compile software with the various GCC floating point options (soft, softfp, or hard) regardless of what the host OS was compiled with?

---

Update: For further clarification, do these compiler options only affect function calls containing the float data type? Would the ABI limitation come into play when dealing with simple programs like this one which only uses floating point operations, and not library function calls using floats?

Compiling the above program with gcc -O0 -S -c main.c results in this assembler output listing. For comparison, here is the assembler output using -O3 instead of -O0. Aside from the -O3 build having pre-computed the integer value as 2, the library call for printf is pretty much the same, as expected.

Answer 1

1. The only problem with hardfloat binaries on softfloat system is application binary interface (ABI) incompatibility. And ABI is about interfacing between libraries. You won't be able to link dynamically to the system libraries if you use wrong ABI. If you provide your own hardfp libraries and configure linker to use them instead of system libraries, there should be no problem with that. Also, you should not have any problems if your binary is statically linked (which means it won't need any dynamic libraries).

2. It should be possible to compile with other floating point options that your system was created but this may require you to create different toolchain for that. This is because of the libraries that has to be linked to your executable which ABI must match ABI of your executable and hardfp toolchain will only contain hardfp libraries.

3. You have to worry about ABI compatibility even if you are not calling functions with floating point arguments/return value and not using floating point at all. This is because linker will always mark your executable with ABI flags and will refuse to link it with libraries with different ABI. Unless you are compiling your executable in static mode, it must be linked with at least libc library.

Answer 2

Theres several seperate but related issues here.

1. kernel support, the kernel must support vfp so it can correctly save the registers.
2. compiler FPU use, does the compiler use the FPU
3. procedure call abi, how are parameters passed to procedures?
4. binary tagging, is the binary tagged with what ABI it uses and does the OS do anything with that information.

Regarding 1 there is a config option (CONFIG_VFP iirc) but I don't think i've ever seen a Pi kernel that didn't have it enabled.

Regarding 2 and 3 gcc has a slightly confusing setting called "-mfloat-abi" with three possible values. If it is set to "soft" then software floating point is used along with the soft float ABI. If it is set to "softfp" then hardware floating point is used but with the soft float ABI. If it is set to "hard" then gcc will use hardware floating point and the hard float ABI.

Regarding 4 I know debian based distros will refuse to load a dynamic library if it doesn't match the declared ABI of the binary. No idea if this behaviour has made it into other distros.

P.S. note that variadic functions like printf don't pass parameters in vfp registers even under the hard float ABI.