[PATCH, ARMEL, FPA] revert-arm-ieee-word-endian.patch - correct newlib-1.18.0 soft FP breakage
Mon Jun 21 10:17:00 GMT 2010
On Monday 21 June 2010 11:23:56 Sebastian Huber wrote:
> I am a little bit surprised why this change has an effect, because of:
> ~/cvs-newlib/newlib > grep -r __IEEE_BYTES_LITTLE_ENDIAN .
> ./libc/include/machine/endian.h:#if defined(__IEEE_LITTLE_ENDIAN) ||
> ./libc/include/machine/ieeefp.h: __IEEE_BYTES_LITTLE_ENDIAN
> ./libc/include/machine/ieeefp.h:# define __IEEE_BYTES_LITTLE_ENDIAN
> Who uses this __IEEE_BYTES_LITTLE_ENDIAN define?
This is now used by machine/endian.h.
Without changes the memory access endianness has
been selected incorrectly, which could lead
to horrible consequences.
The original solution has been incorrect, changes
produce correct defines result in accordance with
GCC internal logic, but I do not like
machine/endian.h logic and tried to mark that
fragile part by (may be over-rude) comment.
But generally there would be great to look
for some better implementation. Something like
GLIBC bits directory. There is partial attempt
in NewLib for that, this is param.h generated
file and config.h.
But I think, that the generated file should not
pollute user namespace (HZ etc). All defines
should be with two underscores __HZ,
#define __BYTE_ORDER __BIG_ENDIAN
etc. Then the parameters should be exposed
to user by standard declared header files
(i.e. endian.h) through include of generated file
and defines like
#define BYTE_ORDER __BYTE_ORDER
At least that is how I feel that clean. But problem
is to do such transition such way, that the
significant breakage for all supported systems
and configurations is prevented.
That is why I have provided less intrusive solution
to fix only found problem. I have tried to provide
full description in original e-mail, but it is
possible that my wording is well readable.
More information about the Newlib