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: [PATCH v2] handle sem_t with ILP32 and __HAVE_64B_ATOMICS

On Mon, Jan 26, 2015 at 8: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  <>
>>         * 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.


> Cheers,
> Carlos.

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