Updated patches for e500 port for uClibc

[Joakim Tjernlund]

> -----Original Message-----
> From: Steve Papacharalambous [mailto:stevep at freescale.com] 
> Sent: 29 January 2007 15:49
> To: Joakim Tjernlund
> Cc: uclibc at uclibc.org
> Subject: RE: Updated patches for e500 port for uClibc
> 
> Hi Joakim,
> 
> Thanks for taking a look at these patches.  Please see in line,
> 
> Best regards,
> 
> Steve
> 
> On Mon, 2007-01-29 at 13:28 +0100, Joakim Tjernlund wrote:
> > > -----Original Message-----
> > > From: uclibc-bounces at uclibc.org 
> > > [mailto:uclibc-bounces at uclibc.org] On Behalf Of Steve 
> Papacharalambous
> > > Sent: 29 January 2007 11:16
> > > To: uclibc at uclibc.org
> > > Subject: Updated patches for e500 port for uClibc
> > > 
> > > Hi,
> > > 
> > > I have updated the patches for the port of the powerpc e500 
> > > architecture
> > > to uClibc.
> > > 
> > > The patches for this port are available from: 
> > > http://www.bitshrine.org/gpp/
> > > 
> > > The patches have been generated and tested against the 
> uClibc snapshot
> > > of uClibc-20070119
> > > 
> > > There are three patches:
> > > 
> > > 1/ uclibc-20070119-e500-libc.patch
> > > This patch adds the basic e500 setjmp/longjmp 
> functionality to uClibc,
> > > splits the powerpc architecture into sub architectures.  
> The existing
> > > generic powerpc code has now been placed in the "classic" sub
> > > architecture, and the e500 is in the "e500" sub architecture.  One
> > > advantage of this is that it should be straightforward to add more
> > > powerpc architectures in the future.
> > 
> > Had a quick look at this one and found two issues:
> > 1)
> >    +	CPU_CFLAGS-$(CONFIG_E500) += "-mcpu=8548 -mhard-float
> > -mfloat-gprs=double"
> > Don't think you should hardcode -mhard-float and 
> -mcpu=8548(don't know
> > what -mfloat-gprs=double does)
> > 
> 
> 
> There are two versions of the e500 core, the e500 v1 which only has a
> SPFP FPU, and the e500 v2 which has a dpfp FPU.
> 
> The reason that these flags are needed is to get gcc-3.4.x e500
> compilers to generate e500 double precision floating point code.  One
> possibility is to condition these flags according to the settings of:
> 
> UCLIBC_HAS_FLOATS
> UCLIBC_HAS_FPU
> UCLIBC_HAS_SOFT_FLOAT

Usally one would pass such flags to the gcc configure pass to make them
default.
An exception would be UCLIBC_HAS_SOFT_FLOAT/UCLIBC_HAS_FPU that could
pass in
msoft-float/mhard-float
 
If that isn't good enough, I think we need an UCLIBC_EXTRA_GCC_FLAGS
config option in uClibc
where one can pass in the needed options during the configure step.

> 
> If this is acceptable I'll rework this area of the patch.
> 
> > 2)
> > +#ifdef __PIC__
> > +	b __sigjmp_save at plt
> > +#else
> > +	b __sigjmp_save
> > +#endif
> > 
> > This breaks SecurePLT, replace with a "b __sigjmp_save at local"
> > SecurePLT was added recently to SVN.
> > 
> 
> OK, will update the patch to fix this.
> 
> > > 
> > > 2/ uclibc-20070119-e500-fpu-except-libm.patch
> > > This patch adds the e500 floating point exception 
> functions to uClibc.
> > > The code in this section has been split into sub 
> architectures in the
> > > same manner as above.
> > > 
> > > 3/ uclibc-20070119-e500-string-libm.patch
> > > This patch adds the e500 SPE string conversion functions 
> to uClibc.
> > > 
> > > Most of the code has been ported from the e500 glibc port, and the
> > > original copyrights and license information have been left intact.
> > > 
> > > Any chance of these patches getting merged into the main sources?
> > > I'd be happy to help out with any effort to get these merged 
> > > in, and in the
> > > future maintenance of them,
> > > 
> > > Best regards,
> > > 
> > > Steve
> > 
> > Didn't look much at the last two patches.
> > 
> > It would help alot if you could separate pure renames from actual
> > changes.
> > 
> 
> Sure, I can split the patches out.  I'm not sure exactly how 
> you'd like
> the patches split.  When you say pure renames are you referring to the
> files that are moved into different sub-directories?
> (sysdeps/linux/powerpc --> sysdeps/linux/powerpc/classic)

Yes, for the moment I would like to see the new code that is added. The
renames to classic
gets in the way.

 Jocke