Dear All
From my point of view, when packing is formally required (ie packets
headers), the structs should be declared explicitly as __packed__. The correctness of the object code should be independent from the compiler optimizations and we should always remember that the offset of a struct field is not necessarily the sum of the sizes of the fields that precede it.
struct { type1 a; type2 b; type3 c; } mystruct
offset(mystruct.c) != sizeof(type1) + sizeof(type2).
Regarding the CFLAGS used by me... I haven't set any CFLAGS and I just do a make qemu_mips_config CROSS_COMPILE=mips-linux- && make CROSS_COMPILE=mips-linux... and a boundary alignment is not an alien choice for a good compiler (a standard gcc4.2.4 in my case). Furthermore I expect a correct object always... with any -Ox flag (a apart bugs... of course).
My idea should be to declare a define like this
#define PKT_HEADER __attribute__((__packed__))
my 2EuroCents.
best regards,
luigi
2009/1/28 Ben Warren biggerbadderben@gmail.com:
Jerry Van Baren wrote:
Ben Warren wrote:
Luigi 'Comio' Mantellini wrote:
Hi ML,
I'm working on a mips target and I used qemu_mips target to simulate my target (that I hope to have in the next week...)
Following my activities I noticed that IP_t structure is no defined with attribute "packed". I noticed this issue because using a self-made toolchain (gcc4.2.4+binutils2.8+uclibc0.9.30) the compiler has aligned all bytes to 32bit boundary. This is not ok, because the packets IP_t can be non aligned (see the /net/net.c PingSend function, for an example).
Why is your compiler aligning all bytes to 32-bit boundary? Seems like an awful waste of space. This struct should pack itself nicely, and does on the small sample of toolchains I've tried (gcc 4.3.2 x86_64 and gcc 4.0.0 ppc_4xx).
The compiler is optimizing for speed and/or execution size at the expense of larger data structures either by command (e.g. a -O option) or as part of the compiler writer's choice. CPUs almost always execute code significantly faster when the data is properly aligned. Many CPUs require software to deal with the misalignment which costs code space and execution time.
Since the compiler wasn't instructed that the IP headers needed to be packed, it is within the compiler's right to not pack them.
Sure. In this case, though, the optimization's not necessarily going to gain anything since we never use a raw struct IP_t, only pointers that overlay other char arrays through casting. Of course there's no point discussing this much further here, but I suspect that this packing problem will exist in many more places than the protocol headers.
[snip]
Best regards, gvb
regards, Ben