This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __IEEE_*_ENDIAN vs. BYTE_ORDER


Jeff Johnston wrote:
Ralf Corsepius wrote:

On Mon, 2004-05-03 at 23:56, Jeff Johnston wrote:

Ralf Corsepius wrote:

On Wed, 2004-04-28 at 23:21, Ralf Corsepius wrote:


On Wed, 2004-04-28 at 22:45, Jeff Johnston wrote:


Ralf Corsepius wrote:


Hi,

Newlib's sys/param.h applies __IEEE_*_ENDIAN (from machine/ieeefp.h) to
define BYTE_ORDER.


AFAIU, __IEEE_*_ENDIAN denotes the floating point endianess, only, which
doesn't necessarily match with a CPU's general endianess.



E.g. some arm-CPUs seem to use __IEEE_BIG_ENDIAN, while actually being
little endian targets.


On these targets newlib's sys/param.h results into
#define __IEEE_BIG_ENDIAN
#define BYTE_ORDER BIG_ENDIAN

even for little endian arm targets, while I think
#define __IEEE_BIG_ENDIAN
#define BYTE_ORDER LITTLE_ENDIAN

would have been correct.

I.e. I suspect newlib's sys/param.h to be "illegally" using
__IEEE_*_ENDIAN to setup BYTE_ORDER. I am wrong or right?


Newlib's sys/param.h is simply defaulting. Note that it checks to see if BYTE_ORDER is already defined. In special cases such as the ARM where the byte order and the floating-point byte order don't match up, the sys/config.h file should have defined the BYTE_ORDER as appropriate.


I believe the attached patch should do the trick.


Thanks, I see how this works.

However, wouldn't it be cleaner to separate BYTE_ORDER from
__IEEE_*_ENDIAN, to implement a sys/endian.h header and use this header


Sorry, typo: s,sys/endian.h,machine/endian.h,



in sys/params.h, similar to the way BSD handles this issue?


I went back and took another look at this.


FYI: I haven't yet tried your patch, yet and have been patch using a
machine/endian.h instead.


Actually, sys/param.h is already being overridden when necessary by various platforms. The ARM is one of these and you will see a special sys/param.h in the libc/sys/arm directory.



Well, I should have been more precise: My target is arm-rtems. This target applies libc/sys/rtems/param.h and ignores libc/sys/<cpu>/param.h

<thinking> Why libc/arm/sys/param.h? Shouldn't sys/*.h headers be reserved for
OS-dependent headers and shouldn't architecture dependent headers better
go to machine/*.h?
</thinking>



Yes and yes, but historically this hasn't always been followed.


In this file, a check is made for __ARMEB__ rather than the default above.



Hmm, I need to check the details, but if what you say applies, this would either mean a bug in RTEMS support files in newlib or a general issue configuration issue in newlib.


I have begun putting a patch together that has the default sys/param.h include both a machine/endian.h and a machine/param.h. The reason for the machine/param.h is that ARM currently redefines HZ to 100 in sys/arm/sys/param.h. I am moving this to machine/arm/machine/param.h. I am also removing sysvi386/sys/param.h as it should be able to use the default now.


Both linux and RTEMS have their own sys/param.h and machine/param.h. Both are consistent and won't use the default include files. The linux directory actually has set up its own machine structure so it can add future platforms. The RTEMS directory will only get the one machine/param.h unless it overrides this outside of newlib.

-- Jeff J.


I have checked the patch in. I modified the RTEMS sys/param.h to include the new machine/endian.h. This should solve your original problem with arm-rtems. Let me know if you run into any problems.


-- Jeff J.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]