This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] handle sem_t with ILP32 and __HAVE_64B_ATOMICS
- From: Andrew Pinski <pinskia at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Chris Metcalf <cmetcalf at ezchip dot com>, Andreas Schwab <schwab at suse dot de>, Torvald Riegel <triegel at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, "H.J. Lu" <hjl dot tools at gmail dot com>, David Miller <davem at davemloft dot net>, Richard Henderson <rth at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, "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: Mon, 26 Jan 2015 20:50:45 -0800
- Subject: Re: [PATCH v2] handle sem_t with ILP32 and __HAVE_64B_ATOMICS
- 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> <1422276280 dot 29655 dot 91 dot camel at triegel dot csb> <54C6A1DD dot 4020004 at ezchip dot com> <1422305739 dot 29655 dot 144 dot camel at triegel dot csb> <87a915b170 dot fsf at igel dot home> <54C6CF4B dot 1020600 at ezchip dot com> <54C71485 dot 8060705 at redhat dot com>
On Mon, Jan 26, 2015 at 8:31 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/26/2015 06:35 PM, Chris Metcalf wrote:
>> This version reflects Torvald's recent comments.
>>
>> 2015-01-25 Chris Metcalf <cmetcalf@ezchip.com>
>>
>> * sysdeps/nptl/internaltypes.h (to_new_sem): Define. Provides new
>> behavior for [__HAVE_64B_ATOMICS && !defined (_LP64)].
>> * nptl/sem_getvalue.c (__new_sem_getvalue): Use to_new_sem.
>> * nptl/sem_init.c (__new_sem_init): Likewise.
>> * nptl/sem_open.c (sem_open): Likewise.
>> * nptl/sem_post.c (__new_sem_post): Likewise.
>> * nptl/sem_timedwait.c (sem_timedwait): Likewise.
>> * nptl/sem_wait.c (__new_sem_wait): Likewise.
>> (__new_sem_trywait): Likewise.
>
> I'm not all that happy with this patch.
>
> For example a statically compiled application sharing a semaphore
> with a dynamically compiled application would appear to break
> under your changes and nothing you can do would fix it. They each
> have different layouts for the semaphore. This is a common problem
> when switching internal layouts (like we did from Linuxthreads to
> NPTL). I accept that you may want to make this change and that this
> particular case might be unsupportable, but I want more discussion
> on the topic.
>
> Similarly H.J's comment to change the alignment of the type
> is equally flawed as embedded sem_t's in other types would break
> other ABIs down the line. I see he's commented on that in a later
> down-thread post.
>
> As far as I can tell the only immediately kosher solution is for
> these machines, that can't use 64-bit atomics because the
> alignment of their sem_t is not correct, is to use 32-bit atomics
> (for now). The choice of 32-bit atomics in no way prevents you
> from future 64-bit atomic uses. You can switch AFAICT to another
> internal implementation at a later date.
>
> Could you switch to 32-bit atomics for 2.21 and continue to
> investigate this optimziation for 2.22?
Since AARCH64:ILP32 is not in yet, it might make sense to use 64bit
atomics for it though we have the same issue as there are now glibc in
the wild with AARCH64:ILP32 support and those would have the same
issue as tile now.
Thanks,
Andrew
>
> Cheers,
> Carlos.
>