From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [Patch 04/18] include/linux/logfs.h From: David Woodhouse To: Segher Boessenkool In-Reply-To: References: <20070603183845.GA8952@lazybastard.org> <20070603184205.GE8952@lazybastard.org> <200706032342.27252.arnd@arndb.de> <20070604091245.GF14823@lazybastard.org> <1180964303.25232.358.camel@pmac.infradead.org> <18f622d94e9273fe6c93ef091fcec87c@kernel.crashing.org> <1181058836.16089.23.camel@hades.cambridge.redhat.com> Content-Type: text/plain Date: Wed, 06 Jun 2007 09:50:20 +0100 Message-Id: <1181119820.25232.434.camel@pmac.infradead.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: akpm@osdl.org, David Weinehall , Dongjun Shin , Kyle Moffett , linux-mtd@lists.infradead.org, Pavel Machek , Sam Ravnborg , Ulisses Furquim , CaT , Evgeniy Polyakov , Roland Dreier , Arnd Bergmann , =?ISO-8859-1?Q?J=F6rn?= Engel , Jamie Lokier , Pekka Enberg , Jan Engelhardt , Thomas Gleixner , Bill Davidsen , Albert Cahalan , John Stoffel , linux-kernel@vger.kernel.org, Ondrej Zajicek , linux-fsdevel@vger.kernel.org, Willy Tarreau List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 2007-06-05 at 20:49 +0200, Segher Boessenkool wrote: > >>> It would be better if GCC had a 'nopadding' attribute which gave us > >>> what we need without the _extra_ implications about alignment. > >> > >> That's impossible; removing the padding from a struct > >> _will_ make accesses to its members unaligned (think > >> about arrays of that struct). > > > > It _might_ make accesses to _some_ of its members unaligned. > > It _will_ make accesses to _at least one_ of the members > unaligned, in the second array element. It _might_, but not necessarily. Won't a simple struct { uint16_t } get padded to a size of 4 bytes on ARM? Even if I'm misremembering that, I certainly can't guarantee that such a thing will _never_ happen on any newly-invented ABI. If you had 'nopadding' instead of 'packed', then there's no need to emit code to handle unaligned loads. Likewise, with a struct which looks like this: { uint32_t, uint16_t, uint16_t, uint32_t, uint32_t } I cannot _guarantee_ that there will never be an architecture on which we'll end up using 32 bits of space for each uint16_t. I might _guess_ that and hope, but that's precisely the kind of moronic empirical behaviour which caused Linux to have so many problems with newer compilers in the past. If it isn't _guaranteed_ then I shouldn't be assuming it. Thus, I want a way to tell the compiler not to insert _any_ padding. But without the compiler making extra inferences about the whole thing being found at arbitrary alignments. And if I had something like this (which is admittedly contrived, but hardware people _do_ do stupid things to us): { uint32_t, uint8_t, uint16_t, uint8_t, uint32_t, uint32_t } With the 'packed' attribute the compiler would assume arbitrary alignment of all the 32-bit integers. But in reality it's only necessary for the uint16_t in the middle. A 'nopadding' attribute would deal with that correctly. -- dwmw2