From owner-svn-src-all@FreeBSD.ORG Tue Feb 2 06:07:51 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58856106568F; Tue, 2 Feb 2010 06:07:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id E1B7D8FC20; Tue, 2 Feb 2010 06:07:50 +0000 (UTC) Received: from c122-106-174-165.carlnfd1.nsw.optusnet.com.au (c122-106-174-165.carlnfd1.nsw.optusnet.com.au [122.106.174.165]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1267ev5006976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 17:07:43 +1100 Date: Tue, 2 Feb 2010 17:07:40 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "M. Warner Losh" In-Reply-To: <20100201.104537.578650865272929831.imp@bsdimp.com> Message-ID: <20100202163610.J80621@delplex.bde.org> References: <201002011413.o11EDiPm074656@svn.freebsd.org> <20100202012830.B1230@besplex.bde.org> <20100201.104537.578650865272929831.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, luigi@FreeBSD.org, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, brde@optusnet.com.au Subject: Re: svn commit: r203343 - head/sys/netinet X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 06:07:51 -0000 On Mon, 1 Feb 2010, M. Warner Losh wrote: > In message: <20100202012830.B1230@besplex.bde.org> > Bruce Evans writes: > : Rev.1.30 attempted to fix this by also adding the __aligned(4) > : attribute. > : I haven't checked that this works. It adds additional unportability > : and > : ugliness. > > __packed is necessary for ARM where the rules of the ABI we use are > such that this structure isn't properly packed otherwise.[*] Is arm's broken ABI really that broken? _This_ struct's correct size is a multiple of 4, so it isn't affected by arm's padding at the end. It takes a broken ABI for bi-fields to give a problem, but arm is not that broken AFAIK (**). I think __packed is just FUD for this struct. > __aligned(4) tells the compiler that pointers to this structure are > 4-byte aligned, which helps on many platforms generate more optimal > code. > > The root cause of all this mess is that 'C' doesn't have any good, > easy ways to specify "on the wire" formats of structures. So we have > to play these games to make the headers we snarfed off the wire match > the C structs that we're using to access the fields in those > structures. We are necessarily in unportability land here. It is > only by the chance alignment of the x86 ABI and the wire format that > the project was able to ignore the issue for so long... Not really chance. No reasonable ABI requires excessive alignment. This is depended on in 100's of other places, especially in device drivers. Some of the other places don't even use __packed. Their problems on arm have apparently been limited by a combination of not using bit-fields and > [*] Of course, it could be argued that ARM should use a different > and/or better ABI for newer cores, and I'd agree with that... But > until that's fixed, we have to cope. Even while waiting for the fix, it would be nice to use a local fix -munbroken-alignment, in one MD place (Makefile.arm, although that won't work for headers that are (ab)used in userland), instead of engrotting 100's of "MI" places hacks like __packed. Of course it's a hack to use a struct at all. (**) I couldn't find any documentation of the alignment for bit-fields in gcc.info, except this for powerpc: % `-mno-bit-align' % `-mbit-align' % On System V.4 and embedded PowerPC systems do not (do) force % structures and unions that contain bit-fields to be aligned to the % base type of the bit-field. % % For example, by default a structure containing nothing but 8 % `unsigned' bit-fields of length 1 would be aligned to a 4 byte % boundary and have a size of 4 bytes. By using `-mno-bit-align', % the structure would be aligned to a 1 byte boundary and be one % byte in size. This says that the -mno-bit-align option may be used to turn off excessive alignment for the struct, but only for powerpc. Reading between the lines, it says that powerpc normally has the same behaviour as i386 -- it is not so broken as to align the individual 1-bit bit-fields to a 4-byte boundary. Whether it adds 3 bytes of useless padding at the end of the bit-fields to pad them to sizeof(unsigned) is less clear. Bruce