[U-Boot] powerpc: FOO uses hard float, BAR uses soft float

[Stephen Warren]

On 12/08/2011 03:09 PM, Wolfgang Denk wrote:
> Hi,
> 
> I'm looking for help to get rid of linker warnigns like these:
> 
> -> ./MAKEALL sequoia
> Configuring for sequoia - Board: sequoia, Options: SEQUOIA
> powerpc-linux-ld: Warning: 20010226-1.o uses hard float, libpostpowerpcfpu.o uses soft float
> powerpc-linux-ld: Warning: acc1.o uses hard float, libpostpowerpcfpu.o uses soft float
> powerpc-linux-ld: Warning: /opt/eldk-5.1/powerpc/sysroots/powerpc-linux/usr/lib/powerpc-linux/4.6.1/libgcc.a(darwin-ldouble.o) uses hard float, u-boot uses soft float
> 
> These warnings are cause by the fact that we always build U-Boot with
> "-msoft-float", but boards that have POST enabled may pull in the FPU
> test code, which naturally will have to be compiled with
> "-mhard-float" instead.
> 
> Is there any way to silence these warnings (ideally only for these
> specific set of files, where we know they are to be expected) ?

I'm not familiar with PPC, but below I describe the situation for ARM;
if it's similar, this should be useful...

soft and hard float are incompatible ABIs. You can't mix code that's
compiled with different ABIs. That's what the linker is complaining about.

The solution may be to build U-Boot with -mfloat-abi=hard, but disallow
FP usage through some other means (I /think/ there's a separate gcc flag
for this).

Alternatively, the FPU test code could be built with -mfloat-abi=softfp.
That allows FPU usage (especially true if it's via inline assembler
etc.!), but has an ABI compatible with -mfloat-abi=soft.


I wrote up more background notes on this for our internal wiki:

Not all ARM CPUs have a floating-point co-processor (FPU), and hence not
all ARM CPUs have the FPU's set of dedicated floating-point (FP) registers.

Historically, this has meant that:

    * The calling convention does not pass FP values in the dedicated FP
registers (FPRs), but rather uses the main ARM CPU's regular register set.
    * Compilers don't emit FP instructions into code, but rather emit
calls to utility functions to perform FP operations, such as add or
multiply. The implementation of those utility functions may contain
hand-coded assembler that uses the FPU, or call an FP emulation library;
the choice is up to the system/OS builder based on their knowledge of
the actual CPU's capabilities.

The above combination yields the FP ABI known as "soft"; gcc option
-mfloat-abi=soft.

When it is known that code will run on CPU(s) with a real FPU, the
compiler may be instructed to emit FP instructions directly into the
code. This benefits performance since a function call is no longer
needed for each FP operation. However, for backwards-compatibility, when
passing FP values between functions, the calling convention is not
changed, and hence the values need to be moved back and forth between
CPU registers and FPRs. This yields the floating point ABI known as
"softfp"; gcc option -mfloat-abi=softfp.

Code using either the "soft" or "softfp" "ABIs" is 100% compatible
(given a CPU that actually has an FPU); the actual ABI is identical
between these two cases, the difference simply being whether FP
operations use FPU instructions directly or not.

Most recent CPUs do actually contain an FPU. In this case, it is
inefficient to constantly move FP values back and forth between CPU
register and FPRs. To address this, a new calling convention was
created, which uses FPRs to pass FP values between functions. This
yields the floating point ABI known as "hard"; gcc option -mfloat-abi=hard.

Code using the "hard" ABI is incompatible with code using either the
"soft" or "softfp" ABIs. The entire system (C library, all shared
libraries, all applications) must be rebuilt using the hard ABI for it
to function correctly because FP values are passed in the FP hardware
registers in the hard ABI.

The user-space <-> kernel-space divide provides a barrier between ABI
requirements. The kernel specifies a completely different syscall-based
ABI and this is not be affected by whether user-space uses the soft or
hard ABI for function calls. This is largely moot as syscalls generally
do not pass or return floating point numbers.

-- 
nvpublic