On Mon, 2004-01-12 at 10:04, Andi Kleen wrote:
> When you use [su]64:
> make sure the data element is explicitely padded to be on a 8 byte boundary
> in the structure. The reason is that alignof(u64) on i386 is 4 but 8 on
> and the structure layout could change.
> also when you use 64bit types make sure the complete structure is padded to 8
> The x86-64 ABI pads any data structure to the alignof() of its biggest member
> to get good alignment for arrays. This is what broke PF_KEY - it is missing
> padding and the structure layout ends up differently with nested structures.
The behavior of some 32 bit archs alignof()e.g ppc is similar in
aligning to its biggest member.
We have some major problems with include/linux/pkt_sched.h::tc_stats for
example; i just have to keep hacking tc on ppc everytime so it doesnt
stop processing and bitch about truncated stats; [this happens when
doing a sizeof() of on-the-wire data passed from the kernel being
compared against sizeof(tc_stats)]. I recall there are a few other
similar structures. It didnt seem like there was a clean solution when i
last looked at this. It seems we may need surgery on a few places like
this and may require a few #ifdefs. Any thoughts on this particular one?