Re: [lwip-users] Struct packing/alignment problems

[Leon Woestenberg]

Hello Kieran,

Kieran Mansley wrote:

> Smiley noted.
Did too. But also am familiar with lotsa processor instruction sequence
assembly. That experience however, does not answer the question in this 
discussion :-)

> "The ARM Linux compilers round the size of structures to a multiple of 4
> bytes and always align structures to a multiple of 4 bytes so that the
> load and store multiple word instructions (ldm and stm) can be used"
> ... 
> Technically the above link is a case for padding the end of a structure,
> rather than between fields in a structure, ...
Exactly, and nothing more than that. I have been browsing around at ARM 
and IBM/Motorola PowerPC documentation, which explicitly list the 
alignment requirements for those.

The natural alignment boundary of a type in bytes is *never* larger than 
the type size in bytes.

I.e. I could not find a case where we need to pack (I am still under
the assumption that compilers always pick the smallest padding
possible to comply with alignment requirements).

Given that TCP/IP header fields use natural alignment (alignment
boundary equals field size), I am now quite convinced that the
"Ethernet header fix" and proper definition of the uX_t variables
will work for all architectures.

(I hope the DSP people are reading this and can confirm this).


> guarantees to not pad structs in the way I've described?  The packed
> attribute specifies that a variable or structure field should have the
> smallest possible alignment, which seems to me to be exactly what we want
>
Packed tells the compiler not to create padding bytes inbetween fields.
Thus, it always uses 1-byte "alignment", i.e. "align on the next byte
address". (I will leave bit fields out of this, we do not (want) to use 
these).

Your choice of words "smallest possible alignment" may still suggest
"smallest possible natural alignment".

> here.  Maybe it's unnecessary, but we should make sure of that before we
> go breaking things, and if it's not tightly specified to be as you say,
> I'd rather leave the packed directives in.  Given that the packed
>
I would rather remove the pack directives; and have someone come up with
a problem report if that breaks stuff.

We know how to pack stuff now, even with the #include method (that was
for a M$ compiler, am I right??), so we can easily revert to this method
might someone find the unusual subject.

> directives (in lwip) are all macros that can easily be redefined by
> anyone for whom it causes a problem, I think I've lost sight of what the
> objection to them was.
Messes up the code unnecessarely.

Regards,

Leon.