On Tue, Feb 21, 2012 at 12:05:54PM +0100, Ulrich Weigand wrote:
Andrew Stubbs andrew.stubbs@linaro.org wrote on 21.02.2012 11:56:07:
I'm not sure, but I believe that the compiler requires (prefers) any structs that you want included inside packed structs to be themselves packed, so you can end up with some structs with apparently unnecessary attributes on them.
I don't see why the compiler would care. Its just that if an inner struct already has padding somewhere, this padding doesn't go away (the struct layout is not recomputed) just because it is embedded in a larger struct which is marked packed. [Marking the outer struct packed will still affect the overall alignment requirement of the inner struct; it just won't affect it inner layout.]
It might also have an effect when you place the struct inside an unpacked struct?
Yes, of course: if the struct is packed, then the struct as a whole has an alignment requirement of 1, which may affect the placement of the struct as an element within an outside (unpacked) struct.
Without context I've no idea whether that's what's going on here. Of course, a no-op "packed" attribute ought to be harmless...
It is not really "no-op": it reduces the alignment requirement of the struct from 2 (in this case) to 1, which is actually exactly what's causing the problems in the original test case.
With packed, the compiler can validly emit misaligned memory accesses, which is bad when building bare-metal code where the underlying memory may be strongly-ordered, since the CPU will throw exceptions in that case.
I don't know whether that applies to this case, though.
I can't see struct pad_conf_entry nested inside anything else, so it just looks unnecessary for this to be packed (I still didn't check the context of this thoroughly, however...)
What happens if that attribute is simply removed from all the affected headers?
Cheers ---Dave