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.