cvs commit: src/include ar.h

[Marcel Moolenaar]

On Nov 18, 2006, at 12:21 PM, Yar Tikhiy wrote:

> On Sun, Nov 19, 2006 at 05:47:40AM +1100, Bruce Evans wrote:
>> On Sat, 18 Nov 2006, M. Warner Losh wrote:
>>
>>> In message: <20061118214618.U15111 at delplex.bde.org>
>>>           Bruce Evans <bde at zeta.org.au> writes:
>>> : On Fri, 17 Nov 2006, M. Warner Losh wrote:
>>> :
>>> : > In message: <20061117201432.X11101 at delplex.bde.org>
>>> : >            Bruce Evans <bde at zeta.org.au> writes:
>>> : > : For that the comment should be something like:
>>> : > :
>>> : > :  	__packed;	/* Align (sic) to work around bugs on arm
>>> (*). */
>>> : > :
>>> : > : but I doubt that arm is that broken.
>>> : > :
>>> : > : (*) See this thread for more details.
>>> : >
>>> : > But they aren't bugs.
>>> :
>>> : Er, this thread gived the details of why they are bugs.
>>>
>>> Wait, is this the ar or the struct ip thing..  Ar is clearly needed,
>>> but I was going to test the packedness on struct ip...  I've just  
>>> had
>>> my first son and am operating on too little sleep :-(.
>>
>> I was mostly talking about struct ip.  Something is needed for struct
>> ar_hdr, since although it has size a multiple of 4 applications  
>> expect
>> it to have alignment 1 but arm gives it alignment 4.  Something is  
>> needed
>> for struct ether_header (which sam recently packed), since it  
>> wants to
>> have size 14 and alignment 2, but arm gives it size 16 and  
>> alignment 4.
>> Nothing shoulded be need for struct ip, since it wants to have  
>> size 20 and
>> alignment 4, and arm gives it that.
>
> The C standard provides no clues as to how structures are packed
> or aligned.  The only thing it says is that objects have alignment
> and it can be the same or not the same for different objects.  That
> is, a future C compiler is allowed to put holes in struct ip, and
> in any struct it wants, unless we use the unportable __packed hack
> -- or abandon the structs in favor of byte-level access to seamless
> data such as hardware or network packets.  That's what I meant by
> struct ip being historically lucky.

Just my $0.02 and I'm in no way claiming to know anything about the
C standard, ... (wait for it) ... but ...

My interpretation of the use of padding is nothing more than holes
that are the result of alignment requirements of adjacent fields.
The interpretation that it means that the compiler can gratuitously
inject bytes between fields is extreme and pessimistic and borders
on insanity :-)

Also, since this discussion is the result of ARM aligning structures
on 4-byte boundaries, I think that the use of __packed to compensate
for excessive alignment is just plain wrong. We have __aligned(x) to
inform the compiler about what the alignment of an object should be
and that's the tool we should use to tell the compiler on ARM that
we in fact want 1-byte alignment. take for example, the following
structure:

struct {
	uint8_t	 a;
	uint16_t b;
};

If we depend on 16-bit alignment, then __aligned(2) will *NOT* pessimize
structure access on architectures that use 16-bit alignment by default
and it tells the ARM compiler that we don't want it aligned on a 4-byte
boundary. The use of __packed will tell the compiler on *ANY*  
architecture
that it cannot assume any alignment and as such will use byte-wise
accesses.

If the compiler on ARM doesn't respect __aligned(x), then that compiler
is broken and should be fixed. The fact that structures are aligned on
a 4-byte boundary is something I cannot cal a bug, but it's certainly
against POLA.

That's all I intend to say...

-- 
Marcel Moolenaar
xcllnt at mac.com