From owner-cvs-src@FreeBSD.ORG Sat Nov 18 21:06:04 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 79AD516A417; Sat, 18 Nov 2006 21:06:04 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EFF943D81; Sat, 18 Nov 2006 21:05:55 +0000 (GMT) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout05/MantshX 4.0) with ESMTP id kAIL5Oxb023189; Sat, 18 Nov 2006 13:05:24 -0800 (PST) Received: from [192.168.1.3] (c-67-164-11-148.hsd1.ca.comcast.net [67.164.11.148]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id kAIL5KEI025206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 Nov 2006 13:05:21 -0800 (PST) In-Reply-To: <20061118202125.GD80527@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> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F361437-69AC-4823-8FF8-506EA450ED2F@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 18 Nov 2006 13:05:15 -0800 To: Yar Tikhiy X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes 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: Sat, 18 Nov 2006 21:06:04 -0000 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 :-) 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@mac.com