> > A u64 was used for the protection key field in siginfo. When the
> > containing union was aligned, this u64 unioned nicely with the
> > two 'void *'s in _addr_bnd. But, on 32-bit, if the union was
> > unaligned, the u64 might grow the size of the union, breaking the
> > ABI for subsequent fields.
Btw., I think this explanation is incorrect, the layout of _addr_bnd is
irrelevant.
What happened on some 32-bit platforms is the following: if u64 has a natural
alignment of 8 bytes (this is rare, most 32-bit platforms align it to 4 bytes),
then the leadup to the _sifields union matters:
typedef struct siginfo {
int si_signo;
int si_errno;
int si_code;
union {
...
} _sifields;
} __ARCH_SI_ATTRIBUTES siginfo_t;
Note how the first 3 fields give us 12 bytes, so _sifields is not 8 naturally
bytes aligned.
Before the _pkey field addition the largest element of _sifields (on 32-bit
platforms) was 32 bits. With the u64 added, the minimum alignment requirement
increased to 8 bytes on those (rare) 32-bit platforms. Thus GCC padded the space
after si_code with 4 extra bytes, and shifted all _sifields offsets by 4 bytes -
breaking the ABI of all of those remaining fields.
On 64-bit platforms this problem was hidden due to _sifields already having
numerous fields with natural 8 bytes alignment (pointers).
If you agree with this analysis then mind updating the changelog accordingly?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
