Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
and it's worked for me. It *might* not be the best layout for caching performance, but for API structures like ioctls I think it's a clean way to go.
Alternatively, add explicit padding in the structures to make them alignment-neutral. Much less clean, but better than having differently-sized structs depending on architecture.
Fixing the unfixable autofs ABI
Posted May 3, 2012 15:41 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
That doesn't fix this structure, as I understand it. The total size of the elements is 300 bytes, but the whole struct must be aligned to 8 bytes on 64 byte architectures, but only needs alignment 4 on the i386 ABI.
Consider this much simpler structure:
On the i386 ABI, sizeof(struct broken) is 12. On the x86-64 ABI, it's 16.
Posted May 3, 2012 15:50 UTC (Thu) by stevem (subscriber, #1512)
Posted May 3, 2012 18:46 UTC (Thu) by nybble41 (subscriber, #55106)
Yes, but if you add padding fields you can ensure the same alignment on all reasonable architectures:
This way sizeof(struct fixed) is 16 bytes on i386 and x86-64. Of course, that doesn't help with the structure from this article, because the smaller i386 alignment was written into the ABI. IMHO, any structures exposed through the ABI should be naturally aligned and marked as "packed", with explicit padding fields where necessary; alignment should not be left to the compiler where ABI compatibility is a concern.
Posted May 3, 2012 19:10 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
That would generally be the best idea, but as you stated, it doesn't fix this structure, because the i386 ABI doesn't require natural alignment for 64-bit types, as per the definition you gave in your other comment. The reason I asked is that i386's ABI is perverse in requiring natural alignment for some, but not all data types. So, I wasn't sure if the concept of "natural" had different meaning in the context of i386's ABI.
IMHO, any structures exposed through the ABI should be naturally aligned and marked as "packed", with explicit padding fields where necessary; alignment should not be left to the compiler where ABI compatibility is a concern.
I tend to agree, and do this myself when I care about the actual layout of a struct. Ok, I usually forego 'packed' since it isn't portable. I instead make the struct a multiple of the largest data type, and force fields onto natural boundaries for their types.
This practice is especially necessary when you have any "wire formats" or "on disk format." You can almost think of packets crossing the kernel/user-space boundary as having "wire format" semantics in this case, with the minor difference that pointers are more meaningful in user-space exchanges than they usually are over, say, a TCP link.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds