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 <gcc@gcc.gnu.org> 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.
