This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.21 - Machine maintainers, please test your machines.
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Chris Metcalf <cmetcalf at ezchip dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, David Miller <davem at davemloft dot net>, Richard Henderson <rth at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, Andreas Schwab <schwab at suse dot de>, "Joseph S. Myers" <joseph at codesourcery dot com>, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, Thomas Schwinge <thomas at codesourcery dot com>, Marcus Shawcroft <marcus dot shawcroft at linaro dot org>, Chung-Lin Tang <chunglin_tang at mentor dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Date: Sun, 25 Jan 2015 17:14:11 -0800
- Subject: Re: glibc 2.21 - Machine maintainers, please test your machines.
- Authentication-results: sourceware.org; auth=none
- References: <54C2BDD7 dot 7000304 at redhat dot com> <54C3B6D5 dot 3090308 at ezchip dot com> <1422119595 dot 29655 dot 42 dot camel at triegel dot csb> <54C5094A dot 8060300 at ezchip dot com> <54C51D94 dot 6030007 at ezchip dot com> <CAMe9rOpOuuC_Bf1eHs9iaiUY6V-fVMHUCKZPAwje_NemBy84wA at mail dot gmail dot com> <20150125215150 dot GA15033 at gmail dot com> <54C569E5 dot 9050305 at ezchip dot com> <CAMe9rOrundPWENuw-Ne=pW6706Rc9RLpkw7Zx859M9G1JRFk0A at mail dot gmail dot com> <54C58E53 dot 9080608 at ezchip dot com>
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.
- References:
- glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.