From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30365 invoked by alias); 19 Feb 2013 17:21:38 -0000 Received: (qmail 30331 invoked by uid 22791); 19 Feb 2013 17:21:37 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Feb 2013 17:21:28 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1JHLQ62012176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Feb 2013 12:21:26 -0500 Received: from spoyarek.pnq.redhat.com (dhcp193-162.pnq.redhat.com [10.65.193.162]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1JHLLHZ029472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2013 12:21:24 -0500 Date: Tue, 19 Feb 2013 17:21:00 -0000 From: Siddhesh Poyarekar To: "Joseph S. Myers" Cc: Richard Henderson , libc-ports@sourceware.org, libc-alpha@sourceware.org Subject: Re: PI mutex support for pthread_cond_* now in nptl Message-ID: <20130219172212.GC25897@spoyarek.pnq.redhat.com> References: <20130218105637.GJ32163@spoyarek.pnq.redhat.com> <5123AB55.2070100@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00044.txt.bz2 On Tue, Feb 19, 2013 at 05:18:20PM +0000, Joseph S. Myers wrote: > There are however two different groups of those headers, those where e.g. > lll_futex_timed_wait ends with > > INTERNAL_SYSCALL_ERROR_P (__ret, __err) ? -__ret : __ret; > > (e.g. powerpc) and those (e.g. s390) where it just ends with a call to > INTERNAL_SYSCALL and relies on the return value of INTERNAL_SYSCALL being > the correct return from the macro. I'm not sure whether those differences > actually serve a useful purpose or whether the return value of > INTERNAL_SYSCALL differs in a relevant way between architectures. >From the very superficial analysis I had done last year, it should be possible to consolidate all that. Siddhesh