[U-Boot] [PATCHv2] powerpc: Minimal private libgcc to build on Debian

[Moffett, Kyle D]

On Apr 13, 2011, at 16:57, Wolfgang Denk wrote:
> In message <1298479238-22114-1-git-send-email-Kyle.D.Moffett at 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