The libm patch is for uClibc.
-Original Message-
From: Hasjim Williams <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Martin Guy <[EMAIL PROTECTED]>, [EMAIL PROTECTED], GCC
Subject: [linux-cirrus] Re: wot to do with the Maverick Crunch patches?
Date: Mon, 31 Mar 2008 15:46:52 +1000
On Sun, 30 Mar 2008 13:45:30 +0100, "Martin Guy" <[EMAIL PROTECTED]>
said:
> Ok, so we all have dozens of these EP93xx ARM SoCs on cheap boards,
> with unusable floating point hardware.
>
> What do we have to do to get the best-working GCC support for Maverick
> Crunch FPU?
>
> Suggest: make open-source project with objective:."to get the
> best-working GCC support for Maverick Crunch FPU". Anyone wanna run
> one, create repositories, set up mailing list etc a la
> producingoss.com, or is the current infrastructure sufficient for a
> coordinated effort?
Honestly, there is little reward in setting up a new mailing list since
no-one has really tried to look into the issue that much. Traffic is so
low on this list (linux-cirrus), so there is little reason to start a
new one.
Reading documentation and working out why things aren't working is a
much better use of time. Running the full C and C++ tests (in gcc) on
the current MaverickCrunch gcc would be a good start.
We need to figure out what bugs are actually introduced by
MaverickCrunch (in C, C++ and std libraries), and fix them.
There is also a floating point testsuite for glibc:
glibc-2.5/math/gen-libm-test.pl
There should be one for uclibc, too...
> As I understand it, mailline GCC with patches in various versions can
> give:
> futaris-4.1.2/-4.2.0: Can usually use floating point in hardware for C
> and C++, maybe problems with exception unwinding in C++. In generated
> ASM code, all conditional execution of instructions is disabled except
> for jump/branch. Loss of code speed/size: negligable.
> Passes most FP tests but does not produce a fully working glibc (I
> gather from the Maverick OpenEmbedded people)
This is probably mainly due to the lack of exception unwinding, i.e.
what is detailed in ARM IHI 0038A. It could also be due to bugs in the
MaverickCrunch engine, which aren't easy to pick up / debug. I suggest
disabling MaverickCrunch double instructions, and working from there.
If you or someone can get it working 100% with glibc then we can move
forward from there.
> Thoughts on a postcard please... any further progress in OE land?
At the moment we only MaverickCrunch in certain parts of our code, by
setting the relevant CFLAGS / CXXFLAGS. We specifically only use float
rather than double, and it all works as it should.
Unfortunately, I haven't gotten glibc working with MaverickCrunch. Lack
of time / motivation / documentation.
I think glibc EABI doesn't support MaverickCrunch, since no-one has
written "working" patches for this yet, e.g.
glibc-2.5/ports/sysdeps/arm/eabi
I'm pretty sure that the old patches that I did write, are incomplete:
http://files.futaris.org/glibc/glibc-crunch.patch
I don't think that ever ended up in the OE tree, since it was never
working correctly. Additionally I don't think the binutils patch has
gone in.
> Cirrus also have a hand-coded Maverick libm that you can link with
> old-ABI binaries - can we incorporate this asm code in mainline?
Is this uClibc libm or glibc libm?
You might be able to use MaverickCrunch with uClibc but the patch
http://mail.busybox.net/lists/uclibc/2007-November/018723.html won't
compile a 100% working uClibc. It compiles but doesn't work as
expected. Not sure if it works correctly with OABI.
I don't think glibc compiles/runs if MaverickCrunch is enabled, because
of the lack of support in the glibc-2.5/ports/sysdeps/arm directory.
If someone can get iwmmxt support working in everything, then we might
be able to do the same for MaverickCrunch, since it is very similar work
to get one ARM coprocessor working as it is to get another working.
Half of the support for the iWMMXt processor has already been written
and there is proper documentation. Currently iwmmxt is only enabled in
certain applications in openembedded (rather than system-wide) because
of this reason. I am not sure if it is only exception unwinding that
isn't working on iWMMXt, or if there is something else that also needs
to be written.
