From owner-cvs-src@FreeBSD.ORG Sun Nov 19 09:35:35 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AA8916A412; Sun, 19 Nov 2006 09:35:35 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA26443D6E; Sun, 19 Nov 2006 09:35:22 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kAJ9ZNM5092981; Sun, 19 Nov 2006 12:35:23 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kAJ9ZG4n092971; Sun, 19 Nov 2006 12:35:16 +0300 (MSK) (envelope-from yar) Date: Sun, 19 Nov 2006 12:35:15 +0300 From: Yar Tikhiy To: Marcel Moolenaar Message-ID: <20061119093515.GF80527@comp.chem.msu.su> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F361437-69AC-4823-8FF8-506EA450ED2F@mac.com> User-Agent: Mutt/1.5.9i Cc: src-committers@freebsd.org, Bruce Evans , jkoshy@freebsd.org, cvs-all@freebsd.org, phk@phk.freebsd.dk, cvs-src@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/include ar.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2006 09:35:35 -0000 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 writes: > >>>: On Fri, 17 Nov 2006, M. Warner Losh wrote: > >>>: > >>>: > In message: <20061117201432.X11101@delplex.bde.org> > >>>: > Bruce Evans 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