[U-Boot] [PATCH] dm: mips: Import libgcc components from Linux

[Mike Frysinger <vapier@gentoo.org>]

On Friday 27 July 2012 15:10:00 Marek Vasut wrote:
> Dear Mike Frysinger,
> > On Friday 27 July 2012 14:35:25 Marek Vasut wrote:
> > > --- a/arch/mips/lib/Makefile
> > > +++ b/arch/mips/lib/Makefile
> > > @@ -34,6 +34,8 @@ else
> > > 
> > >  COBJS-y	+= bootm.o
> > >  endif
> > > 
> > > +COBJS-y	+= ashldi3.o ashrdi3.o lshrdi3.o
> > 
> > pretty sure this belongs behind USE_PRIVATE_LIBGCC
> 
> Good point ... Mike, I was always wondering what this USE_PRIVATE_LIBGCC
> is, can you elaborate please (pour some of your knowledge on me ;-) ) ?

libgcc is a supplemental library that gcc provides that often times contains 
extended routines (usually written in assembly) for implementing math 
functions that the hardware does not provide itself in the form of dedicated 
instructions.  most commonly, this takes the form of multiplication/divide 
routines.  x86 tends to be "fat" and provide instructions like "mul" and 
"div", but embedded arches like arm/blackfin/mips/etc... tend to have simpler 
instructions so we have to implement these in software.

the problem comes in when the toolchain is built targeting an ABI/float model 
that differs from what we want in u-boot.  Linux has long avoided this problem 
by always bundling the libgcc source files directly into its arch/ tree.  it 
pulls in the bare min that it needs, and then never links with -lgcc.

u-boot has taken the opposite approach: it links against -lgcc for math 
routines rather than keeping a copy of its own.  this leads to the problem you 
noticed with mips, but many of us have hit it with arm.

for the longest time, the party line was "use a different toolchain".  but 
that's often impractical (if not almost impossible) for many users/devs, so 
the compromise has been the USE_PRIVATE_LIBGCC knob.  now the ABI of the 
libgcc that comes with your toolchain does not matter because it isn't linked 
in -- we just compile (for the right ABI) local copies of the math routines, 
and then link against those.

personally, i wouldn't mind converting everyone to USE_PRIVATE_LIBGCC (and 
match exactly what Linux has been doing for ages), but i can live with the 
USE_PRIVATE_LIBGCC trade off.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120731/09f01b1e/attachment.pgp>