Re: wrong htons() used?

[Andrew Cagney <ac131313 at cygnus dot com>]

Grant.Edwards@comtrol.com wrote:
> 
> On Thu, Oct 21, 1999 at 05:09:05PM -0400, Scott Bambrough wrote:
> 
> > The problem is in tm-arm.h.  It defines TARGET_BYTE_ORDER_SELECTABLE.
> > The compatibility code in gdbarch.c
> > defaults to big endian (see line 2777).  Add the following to tm-arm.h:
> >
> > #define TARGET_BYTE_ORDER_DEFAULT       LITTLE_ENDIAN
> >
> > I think this will fix your problem.  I have fixed this while merging my
> > target code for Linux with the current ARM target code.  I have
> > defaulted the embedded targets to LITTLE_ENDIAN.  Any objections.
> 
> I'm not sure I understand the fix -- will this require that the
> target ARM processor be running in little-endian mode?

FYI, the endianess of the target can be configured dynamically using:

(gdb) set endian {big,little,auto}

the default is somewhat arbitrary. When set to auto it _should_ pick up
the endianess of the target using information in the header file.  Check
it with:

(gdb) show endian

I think everyone has agreed that that isn't the problem that is occuring
here.

--

Returning to your problem.  I think treating the ``tuned/untuned''
hton*() as the prime suspects is correct.  Posibbly tripped by some name
space polution problem.  Tried a 3 line program on them?  Also, the file
sim/common/sim-endian.c (which I know works :-) might be a useful
reference.

	Andrew