This is the mail archive of the libc-alpha@sourceware.org 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 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


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