This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc 2.21 - Machine maintainers, please test your machines.

On Sun, Jan 25, 2015 at 4:46 PM, Chris Metcalf <> wrote:
> On 1/25/2015 6:05 PM, H.J. Lu wrote:
>> On Sun, Jan 25, 2015 at 2:10 PM, Chris Metcalf <>
>> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]