On Apr 13, 2011, at 16:57, Wolfgang Denk wrote: > In message <[email protected]> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
