[PATCH v2] handle sem_t with ILP32 and __HAVE_64B_ATOMICS

[Chris Metcalf]

On 1/26/2015 11:31 PM, Carlos O'Donell 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?

I am certainly willing to use 32-bit atomics here for now.  The absolutely
minimal change is to change tilegx32 to set __HAVE_64B_ATOMICS to 0.
Obviously the AArch64 ILP32 mode (out of tree) will want to do the same.
And I don't know whether m68k or mips require a similar change or if
they can tolerate unaligned 64-bit atomic operations.  So arguably if
we can decide that my proposed re-aligning change is best, then it also
automatically handles all the other platforms as well.

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com