Fixing the unfixable autofs ABI [LWN.net]

Fixing the unfixable autofs ABI

Posted May 3, 2012 18:46 UTC (Thu) by nybble41 (subscriber, #55106)
In reply to: Fixing the unfixable autofs ABI by jzbiciak
Parent article: Fixing the unfixable autofs ABI

Yes, but if you add padding fields you can ensure the same alignment on all reasonable architectures:

struct fixed
{
    __u64 f1;
    __u32 f2;
    __u32 pad1;
};

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.

(Log in to post comments)

Fixing the unfixable autofs ABI

Posted May 3, 2012 19:10 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

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.