This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: wrong htons() used?
On Fri, Oct 22, 1999 at 10:45:46AM -0400, Scott Bambrough wrote:
>
> > I'm pretty sure that <netinet/in.h> is getting confused by one
> > of the include files in the rdi-remote directory, since that
> > directory is searched first for include files before
> > /usr/include.
>
> My ARM and i386 systems are GLIBC2 based (RedHat 6.x).
>
> On my system htons(x) resolves to:
>
> (x) if __OPTIMIZE__ and __BYTE_ORDER = __BIG_ENDIAN
> __bswap_16(x) if __OPTIMIZE__ and __BYTE_ORDER = __LITTLE_ENDIAN
>
> On my system __BYTE_ORDER is set in <bits/endian.h>
>
> on ARM:
> __BYTE_ORDER == __BIG_ENDIAN if __ARMEB__ is defined
> __BYTE_ORDER == __LITTLE_ENDIAN otherwise
>
> on i386:
> __BYTE_ORDER == __LITTLE_ENDIAN always
>
> In the preprocessed output of etherdrv.c with optimization on is
> htons(x) reduced to (x) or a call to __bswap_16(x)?
htons(x) with optimization on reduces to (x)
htons(x) with optimization off reduces to htons(x)
> The answer to this should tell you if __BYTE_ORDER == __BIG_ENDIAN
> or __LITTLE_ENDIAN.
Apparently it is __BIG_ENDIAN. Which is wrong, since it's a 386.
> After that you will need to find out why either __BIG_ENDIAN is defined
> or __bswap_16(x) fails. Of course this assumes you have a GLIBC2 based
> system.
I do. (RH6.0)
--
Grant Edwards
grante@visi.com