Re: Re: Networking defect for ARM’bsp intcp_input().

ray xr at trasin.net
Tue Jul 4 14:15:26 UTC 2006


Hi
In fact, the code only wrong when ENDIAN is considered
If change the code :
#if BYTE_ORDER == LITTLE_ENDIAN
	u_int	th_x2:4,		/* (unused) */
		th_off:4;		/* data offset */
#endif
#if BYTE_ORDER == BIG_ENDIAN
	u_int	th_off:4,		/* data offset */
		th_x2:4;		/* (unused) */
#endif

To:
	u_int	th_x2:4,		/* (unused) */
		th_off:4;		/* data offset */

the code works fine

It also interesting that I find that both the following code would not compile:
A: only use little endian
#if BYTE_ORDER == LITTLE_ENDIAN
	u_int	th_x2:4,		/* (unused) */
		th_off:4;		/* data offset */
#endif

B: only use big
#if BYTE_ORDER == BIG_ENDIAN
	u_int	th_off:4,		/* data offset */
		th_x2:4;		/* (unused) */
#endif
Both instance can not find member: th_off


The question is:
1 why ¡°#if BYTE_ORDER¡±used here, byte order base on 8bit byte, not 4bit, am I right?
2 The arm-gcc always generate little endian code by default, but why BYTE_ORDER == LITTLE_ENDIAN fails?



My gcc(downloaded from rtems.com) configuration is:
$ arm-rtems-gcc -v
Reading specs from /opt/rtems-4.6/lib/gcc-lib/arm-rtems/3.2.3/specs
Configured with: ../gcc-3.2.3/configure --build=i686-pc-linux-gnu --host=i386-cygwin --target=ar
m-rtems --with-gnu-as --with-gnu-ld --with-newlib --verbose --with-system-zlib --disable-nls --e
nable-version-specific-runtime-libs --enable-threads=rtems --prefix=/opt/rtems-4.6 --enable-lang
uages=c,c++
Thread model: rtems
gcc version 3.2.3 (OAR Corporation gcc-3.2.3-20040420/newlib-1.11.0-20030605-4)

I check the latest Netbsd code, ¡°#if BYTE_ORDER¡± still remains, there should be a reason, but I can not figure out.


Thanks & Best Regards !
------------------
ray
2006-07-04

-------------------------------------------------------------
from£ºRalf Corsepius
Date£º2006-07-04 17:19:59
to£ºray
CC£ºRTEMS Users
Subject£ºRe: Networking defect for ARM¡¯bsp intcp_input().

On Tue, 2006-07-04 at 00:13 +0800, ray wrote:
> Hi:

> Seems we get the unused data instead of th_off.

If what you say is true, it should be reproducible with the code samples
below. I don't "speak arm-asm", so I can't judge.

Compile the code snippets with:
arm-rtems4.7-gcc -o bla1.o --save-temps -c bla1.c
arm-rtems4.7-gcc -o bla2.o --save-temps -c bla2.c

and then diff the *.s:

# diff -u bla1.s bla2.s
@@ -12,8 +12,8 @@
        sub     sp, sp, #4
        str     r0, [fp, #-16]
        ldr     r3, [fp, #-16]
-       ldrb    r3, [r3, #0]
-       and     r3, r3, #15
+       ldrb    r3, [r3, #0]    @ zero_extendqisi2
+       mov     r3, r3, lsr #4
        and     r3, r3, #255
        mov     r0, r3
        ldmfd   sp, {r3, fp, sp, pc}

Is this code correct? Are the bitfields accessed correctly?

Ralf







More information about the users mailing list