[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patches] E500 port
- To: Joseph S. Myers <joseph@xxxxxxxxxxxxxxxx>
- Subject: Re: [patches] E500 port
- From: Kumar Gala <galak@xxxxxxxxxxxxxxxxxxx>
- Date: Sun, 10 Dec 2006 17:48:36 -0600
On Dec 10, 2006, at 3:47 PM, Joseph S. Myers wrote:
On Fri, 8 Dec 2006, Kumar Gala wrote:
2. need patches for long double ?? is this just an eglibc
requirement?
glibc 2.4 and later for PowerPC requires 128-bit IBM long double
support.
This was added to GCC 4.1 branch for 6xx hard float at a very late
stage
before 4.1 was released, but the soft float support is not yet on GCC
trunk because of FSF policies (it requires a soft-fp patch, and
soft-fp
can only be imported into FSF GCC unmodified from FSF glibc, and
FSF glibc
maintainers have no interest in applying soft-fp patches), so the
EGLIBC
prerequisites page points to the required soft float patches (which in
turn are needed by the E500 long double support patches).
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.
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?
Any help in getting this going would be appreciated. I'd be happy
to look
into implementing the kernel side trap handling and fixup if I can
get an
environment working to show the issues. [Wasn't sure if you aware
there isn't
any code today that does this]
I was told some time ago that Freescale might be implementing this
some
time this year, but I do not know the current status.
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?
- k