??: PR 1098: "struct ipovly" not packed.

[ray]

The trouble is, we put the Ethernet header£¬TCP/IP head together into the mbuf, the Ethernet head's length is 14 byte.
So, when we init ti(in tcp_input/udp_input) with
ti = mtod(m, struct tcpiphdr *);
the start address of ti is not 32bit align. then the first member ti->ti_next's address is not 32bit align.
When not specify packed, GCC DO not know that ti_next start from address like 0x2000000E, the instruction ti->ti_next=0 will interpreter to a simple instruction
*(0x2000000E)=(int32)0;
That causes the abort in ARM.

If add packed, the GCC interpreter the instruction into two(maybe four) instruction like
*(0x2000000E)=(int16)0;
*(0x2000000E+2)=(int16)0;
That is OK for ARM


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

-------------------------------------------------------------
from£ºRalf Corsepius
Date£º2006-07-12 09:21:45
to£ºJay Monkman
CC£ºDenny.Bai; Chris Johns; RTEMS Users
Subject£ºRe: ??: PR 1098: "struct ipovly" not packed.

On Tue, 2006-07-11 at 12:52 -0500, Jay Monkman wrote:
> Ralf Corsepius wrote:
> >
> > structs like the ones above are BAD DESIGN.
> >
> > With or without __attribute((packed))__ there is no guarantee they will
> > work. If you have a look into the BSD structures we are talking about
>
> That's not what the gcc docs say:
GCC != C

>      The `packed' attribute specifies that a variable or structure field
>      should have the smallest possible alignment--one byte for a
>      variable, and one bit for a field, unless you specify a larger
>      value with the `aligned' attribute.
>
> If __attribute__((packed)) is so wrong,
It isn't "so wrong", it's "hack", "band-aid", "means of last-resort" or
whatever you want to call it.

>  what's the correct way to ensure a data
> structure is packed?
Not relying on packing.

struct { int; short; int;} requires packing,
struct { int; int; short;} shouldn't.

The test case I sent last week had proven that arm-gcc packs them
correctly => "packing" is not the explanation for the symptoms.

The still open question is "What is going wrong and where?"

>  If you look at the latest code in netbsd,
NetBSD != FreeBSD.

>  they use it on
> their network data structures:
> http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/netinet/tcp.h?rev=1.19.4.1&content-type=text/plain
The fact others use it, doesn't mean much.

Ralf