glibc 2.21 - Machine maintainers, please test your machines.

[Chris Metcalf]

On 1/25/2015 6:05 PM, H.J. Lu wrote:
> On Sun, Jan 25, 2015 at 2:10 PM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>> On 1/25/2015 4:51 PM, H.J. Lu wrote:
>>
>>> This is for x86.  Each target can do something like it if needed.
>>
>> This does change the ABI for existing code, however, which may legitimately
>> have sem_t objects that are only aligned to 4-byte boundaries.  Your change
>> is a good idea for new platforms.  I suppose we could also do something
>> with symbol versioning to use it for existing 32-bit platforms with
>> 64-bit atomics, too.  So there seem to be multiple fixes we can consider.
>>
> It doesn't change the size, only increases alignment from 4 bytes to 8 bytes.
> It may not work on all targets.  It works for x32.

The size is not the issue I'm referring to; it's the alignment.

Imagine you have some code built against glibc 2.20 or older, where the
user has written:

   sem_t my_sem;

Given the 4-byte alignment constraints, this could result in my_sem
being aligned to 4 bytes but not to 8 bytes.  Now if we were to make the
change you propose for glibc 2.21, the user passing this semaphore to
sem_post() could be passing a pointer not aligned to 8 bytes, despite
the new headers saying that that was required.  Bang, bus error -- or on x32,
presumably, worse performance even if it performs correctly.

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com