glibc 2.21 - Machine maintainers, please test your machines.

[H.J. Lu]

On Sun, Jan 25, 2015 at 4:46 PM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
> 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.
>

Realign new_sem requires a few instructions.  For x32, the performance
gain may be a wash.  For x32, I prefer to align sem_t to 8 bytes.


-- 
H.J.