From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32422 invoked by alias); 16 May 2012 21:58:01 -0000 Received: (qmail 32412 invoked by uid 22791); 16 May 2012 21:58:00 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 May 2012 21:57:48 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1SUmE6-0002gi-Qb from joseph_myers@mentor.com ; Wed, 16 May 2012 14:57:47 -0700 Received: from digraph.polyomino.org.uk ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2012 22:57:45 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.74) (envelope-from ) id 1SUmE4-0002r5-4s; Wed, 16 May 2012 21:57:44 +0000 Date: Wed, 16 May 2012 21:58:00 -0000 From: "Joseph S. Myers" To: Roland McGrath cc: libc-ports@sourceware.org, "Ryan S. Arnold" Subject: Re: powerpc-nofpu ABI baselines In-Reply-To: <20120516214148.19DA22C0A8@topped-with-meat.com> Message-ID: References: <20120516214148.19DA22C0A8@topped-with-meat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: 2012-05/txt/msg00101.txt.bz2 On Wed, 16 May 2012, Roland McGrath wrote: > > @@ -1845,6 +1844,31 @@ > > __xpg_sigpause F > > __xstat64 F > > _flushlbf F > > + _q_add F > > > > [...] > > > > See . These > > functions are in GLIBC_2.2 version but would not have been in glibc 2.2 > > and would never actually have been useful. Do we want to record them as > > part of the GLIBC_2.2 ABI to preserve, or remove them? > > The relevant question is when the bug came in such that _q_add was > exported. If it has been that way for some widely-used versions, then > it's likely that there are binaries referring to the symbol. In that > case, we can't really take it out even though it's an inaccurate > representation of what 2.2 was. The symbols came in when glibc was built with a compiler supporting 128-bit long double. If versions before 2.4 were built like that, the result would be entirely ABI-incompatible with any current libc; it's 2.4 that got the proper support for 128-bit long double on powerpc, with all the affected functions having GLIBC_2.4 symbol versions for the versions using 128-bit long double so that older binaries built with 64-bit long double continue to use older versions of functions built for 64-bit long double. So we can consider the symbols to have come in at version 2.4. In glibc 2.4, sysdeps/unix/sysv/linux/powerpc/configure.in ensures that 128-bit long double is supported and ensures that glibc is built with -mabi=ibmlongdouble (and sysdeps/ieee754/ldbl-128ibm/Makefile ensures -mlong-double-128 is used). The ABI since 2.4 has been the use of 128-bit IBM long double. The _q_* functions, however, are helper functions for IEEE quad long double. GCC will only ever generate calls to them if -mabi=ieeelongdouble. -mabi=ieeelongdouble is entirely ABI-incompatible with IBM long double, as used in glibc 2.4 and greater. Since the functions in question are not built with -mabi=ieeelongdouble, they do not even provide the correct interface for any object built with -mabi=ieeelongdouble (IEEE quad long doubles being passed by reference); calls to them would never have done anything useful. The function _q_utoq, to which GCC might generate calls with -mabi=ieeelongdouble, is listed in Versions but not exported because the source file calls it _q_uitoq. -- Joseph S. Myers joseph@codesourcery.com