cvs commit: src/include ar.h

[Yar Tikhiy]

On Sat, Nov 18, 2006 at 01:05:15PM -0800, Marcel Moolenaar wrote:
> 
> 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 :-)

Quoting C99, 6.7.2.1:

	Each non-bit-field member of a structure or union object is
	aligned in an implementation-defined manner appropriate to its
	type.
	...
	There may be unnamed padding at the end of a structure or
	union.

That is, we can know how GCC aligns and packs structures, but a
different compiler may have different, although documented, rules
for that.  E.g., a pure 64-bit compiler may arrange struct ip so
that its sizeof is a multiple of 8 bytes, e.g., 24, let alone the
alignment of individual members.

> 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:

According to GCC docs, __aligned(x) alone cannot decrease alignment.
It has to be used along with __packed for that.

> struct {
> 	uint8_t	 a;
> 	uint16_t b;
> };

How do you assume this structure is laid out on byte level?  Can there
be a hole between a and 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
> 

-- 
Yar