Messages in this thread | | | Subject | Re: [Patch 04/18] include/linux/logfs.h | From | David Woodhouse <> | Date | Wed, 06 Jun 2007 09:50:20 +0100 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |