On Apr 13, 2011, at 16:57, Wolfgang Denk wrote:
In message 1298479238-22114-1-git-send-email-Kyle.D.Moffett@boeing.com you wrote:
Standard Debian powerpc and powerpcspe systems only include hard-float libgcc in their native compilers, which causes scary build warnings when building U-Boot.
Debian and other PowerPC-supporting distributions used to provide libgcc and other libraries in a "nof" (soft-float) form in the "multilib" packages. As they were completely unused by the distribution and therefore tended to be very buggy it was decided to save some time on the part of the maintainers and build-servers by removing them.
Admittedly, right now the linker warnings do not indicate any problems, as the included routines do not use any floating point at all.
The concern is that if floating-point code were ever added it might cause hard-float code to be unexpectedly included in U-Boot without generating a hard error. This would cause unexplained crashes or indeterminate results at runtime.
The easiest way to resolve this is to borrow the routines that U-Boot needs from the Linux kernel, which has the same issue.
Specifically, the routines are: _ashldi3(), _ashrdi3(), and _lshrdi3().
Sorry, but I cannot follow your logic.
First, we do not use floating point in U-Boot. We don't. Period. [The only exception being well-designed and hand-crafted assemby code where it is unavoidable - for example in the POST code to test the FPU, or for certain atomic 64 bit stores].
So FP support should never be a reason for such a change.
The concern is not with floating point being used in U-Boot, but with the internal implementation of those libgcc functions.
Specifically, I could very well imagine that functions such as the full 64-bit divide (_udivdi3) might internally be optimized by using specific floating point operations on PowerPC.
On PowerPC with SPE extensions, the native libgcc might use the full 64-bit extensions to the regular integer registers to perform such operations.
What confuses me completely is why you then add some shift functions, which are completely unrelated to FP operations.
Since that CPU state is not necessarily set up in U-Boot, we should not use functions from a libgcc which is allowed to use those ops.
Since a native PowerPC U-Boot built on a PowerPC Debian system does not have a soft-float libgcc to build against, this patch provides a minimal "libgcc" with the few libgcc functions that U-Boot seems to need (the various 64-bit shifts).
This is similar to the minimal "libgcc" provided by the ARM arch from arch/arm/lib/_ash[lr]di3.S and arch/arm/lib/_divsi3.S, and is almost identical to what the Linux kernel uses on PowerPC.
This is only enabled if USE_PRIVATE_LIBGCC=1 (the same config variable as the ARM private libgcc) to avoid breaking other ports.
I will update the patch notes.
Cheers, Kyle Moffett