Date: Sun, 19 Nov 2006 12:35:15 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Marcel Moolenaar <xcllnt@mac.com> Cc: src-committers@freebsd.org, Bruce Evans <bde@zeta.org.au>, jkoshy@freebsd.org, cvs-all@freebsd.org, phk@phk.freebsd.dk, cvs-src@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/include ar.h Message-ID: <20061119093515.GF80527@comp.chem.msu.su> In-Reply-To: <1F361437-69AC-4823-8FF8-506EA450ED2F@mac.com> References: <20061117201432.X11101@delplex.bde.org> <20061117.105304.1769993002.imp@bsdimp.com> <20061118214618.U15111@delplex.bde.org> <20061118.110343.58444366.imp@bsdimp.com> <20061119052526.S16985@delplex.bde.org> <20061118202125.GD80527@comp.chem.msu.su> <1F361437-69AC-4823-8FF8-506EA450ED2F@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@delplex.bde.org>
> >>> Bruce Evans <bde@zeta.org.au> writes:
> >>>: On Fri, 17 Nov 2006, M. Warner Losh wrote:
> >>>:
> >>>: > In message: <20061117201432.X11101@delplex.bde.org>
> >>>: > Bruce Evans <bde@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@mac.com
>
--
Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061119093515.GF80527>