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 <biggerbadder...@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
>
--
Luigi 'Comio' Mantellini
R&D - Software
Industrie Dial Face S.p.A.
Via Canzo, 4
20068 Peschiera Borromeo (MI), Italy
Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
web: www.idf-hit.com
mail: luigi.mantell...@idf-hit.com
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
