Re: [patches] E500 port

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Sun, 10 Dec 2006, Kumar Gala wrote:

> Hmm, what exactly is the requirement in glibc?  I know I've built a glibc-2.5
> for a ppc32 system w/o hardware long double support.

glibc for PowerPC requires to be able to build with -mlong-double-128 and 
to get 128-bit IBM long double.  It doesn't care about how this long 
double is implemented, so you have options

(a) based on PowerPC 6xx hardware double floating point, supported in GCC 
4.1;

(b) based on soft-float double floating point, which needs the patch 
detailed on the prerequisites page;

(c) based on E500v2 hardware double floating point, which needs my patch 
as well as (b);

(d) based on soft-float double but building for E500v1, which also needs 
my patch as well as (b).

The PowerPC hardware never supports long double directly, it's the design 
of IBM long double (double+double) that it can be efficiently implemented 
on top of hardware support for double floating point.

> > > 3. some additional patches for gcc-4.1.x for e500?
> > 
> > Yes, as detailed in my message.
> 
> Would a recent gcc-4.1.x branch + the patch you referenced be enough or are
> there more patches on top of that for e500?

I referenced *three* GCC patches *not* one: (i) the one (soft-float long 
double support) needed for building EGLIBC for any form of PowerPC other 
than 6xx hard float (as detailed on the EGLIBC website at 
<http://www.eglibc.org/prerequisites>), (ii) the one needed to get E500 
support back into working shape 
<http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01700.html>, and (iii) the 
one needed to add E500 long double support on top of soft-float long 
double support (branches/csl/sourcerygxx-4_1 revision 119585).  You need 
*all three*, and (i) and (ii) overlap so you need to be careful in merging 
them; they may also overlap with or conflict with other patches present on 
4.1 branch.

Of course proper care needs to be taken to validate the resulting 
toolchain, as built in your environment, thoroughly.  You will need to be 
ready to debug problems shown in validation that may indicate problems 
with the merge or with lack of other patches present in my testing.

> > If the trap handling uses the kernel's copy of glibc's soft-fp, note that
> > I found and fixed many bugs in glibc's soft-fp (and some more are fixed in
> > EGLIBC as part of the PowerPC soft-float work) and these many fixes need
> > merging into the kernel's copy if they haven't already been merged.
> 
> I know we haven't merged any recent changes into the fp emulation code in the
> kernel.  Have you been using a particular test suite to find these issues?

The soft-fp bugs were found by code inspection and testing in the course 
of speeding it up.  For details see my libc-alpha messages between 
December 2005 and February 2006 inclusive, where I wrote up descriptions 
of the bugs found, and note Richard Henderson's comment in the discussion 
that "we'll need to merge this into the linux kernel sources to fix the 
same problems there".  The ucbtest testsuite was used for some testing.  
Further bugs were found in the course of the soft-float long double 
implementation, see glibc bug 2749 for more details and history.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx