This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Monday 25 October 2010 21:21:41 Jeppe Ledet-Pedersen wrote: > Hi everybody, > > This question was originally posted on the crossgcc mailing list, but my > problem appears to be related to Newlib so I'll repost it here. My > original question can be found at > http://sourceware.org/ml/crossgcc/2010-10/msg00147.html > > I have successfully compiled a toolchain for my arm7tdmi with > crosstool-NG. I use GCC 4.5.1, Newlib CVS and Binutils 2.20.1. I have > enabled the EABI and software floating point. Hello Jeppe, I am replying, because we have problem in similar area but it was vice verse. The bad NEWlib access to doubles when GCC compiled correctly FPA format but NEW lib accessed the first word as least significant. There has been more problems in this area with NEWlib 1.18.0. Some third party attempts to fix right byte endianing from NEWlib headers even caused total mess in FP endianess. I hoped, that changes incorporated into actual NEW lib CVS should work for all cases (analyzed together with GCC-4.4.4 sources). The core components which has to correspond are ---------------------------------------- /newlib/libc/include/machine/ieeefp.h ---------------------------------------- #ifdef __VFP_FP__ # ifdef __ARMEL__ # define __IEEE_LITTLE_ENDIAN # else # define __IEEE_BIG_ENDIAN # endif #else # define __IEEE_BIG_ENDIAN # ifdef __ARMEL__ # define __IEEE_BYTES_LITTLE_ENDIAN # endif #endif #endif ---------------------------------------- newlib/libc/include/machine/endian.h ---------------------------------------- #ifndef BYTE_ORDER #if defined(__IEEE_LITTLE_ENDIAN) || defined(__IEEE_BYTES_LITTLE_ENDIAN) #define BYTE_ORDER LITTLE_ENDIAN #else #define BYTE_ORDER BIG_ENDIAN #endif #endif The constants are used in newlib/libm/common/fdlibm.h newlib/libc/stdio/vfieeefp.h The second one uses curious renaming to source original architecture influenced IEEE_8087 or IEEE_MC68k for __IEEE_LITTLE_ENDIAN or __IEEE_BIG_ENDIAN If your code and NEWlib build use same set of switches and defines > If I i run "arm-unknown-eabi-cpp -dD" my toolchain defines both > __ARMEL__, __SOFTFP__ and __VFP_FP__ which should be taken into account then the __VFP_FP__ and __ARMEL__ should select right defines in ieeefp.h -> __IEEE_LITTLE_ENDIAN defined and __IEEE_BYTES_LITTLE_ENDIAN left unset and all parts should interpret doubles same way. I would suggest to check, that the right build options for newlib build are selected. You can modify newlib/libc/stdio/vfprintf.c with #ifdef __IEEE_LITTLE_ENDIAN #warning __IEEE_LITTLE_ENDIAN is selected #endif #ifdef __IEEE_BIG_ENDIAN #warning __IEEE_BIG_ENDIAN is selected #endif #ifdef __IEEE_BYTES_LITTLE_ENDIAN #warning __IEEE_BYTES_LITTLE_ENDIAN is selected #endif #ifdef IEEE_8087 #warning IEEE_8087 is selected #endif #ifdef IEEE_MC68k #warning IEEE_MC68k is selected #endif and you should see only __IEEE_LITTLE_ENDIAN and IEEE_8087 for your variant build. If you use multilib, then you should check, that you really use that library variant which prints "__IEEE_LITTLE_ENDIAN is selected" and "IEEE_8087 is selected" Best wishes, Pavel Pisa ================================================== PiKRON s.r.o. Phone/Fax: +420 2 84684676 Kankovskeho 1235 Phone: +420 2 84684676 182 00 Praha 8 WWW: http://www.pikron.com/ Czech Republic e-mail: pikron@pikron.com ================================================== -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |