From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9284 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: musl libc for PPC64 Date: Mon, 8 Feb 2016 15:18:03 -0500 Message-ID: <20160208201802.GB9349@brightrain.aerifal.cx> References: <20160208161758.GG9915@port70.net> <20160208165143.GA9349@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1454962708 4558 80.91.229.3 (8 Feb 2016 20:18:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Feb 2016 20:18:28 +0000 (UTC) Cc: musl@lists.openwall.com To: David Edelsohn Original-X-From: musl-return-9297-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 08 21:18:27 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aSsGO-0004hW-3k for gllmg-musl@m.gmane.org; Mon, 08 Feb 2016 21:18:24 +0100 Original-Received: (qmail 27830 invoked by uid 550); 8 Feb 2016 20:18:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 27812 invoked from network); 8 Feb 2016 20:18:20 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9284 Archived-At: On Mon, Feb 08, 2016 at 12:48:48PM -0500, David Edelsohn wrote: > On Mon, Feb 8, 2016 at 11:51 AM, Rich Felker wrote: > > On Mon, Feb 08, 2016 at 05:17:58PM +0100, Szabolcs Nagy wrote: > >> * David Edelsohn [2016-02-08 09:43:08 -0500]: > >> > What work is necessary to enable basic musl libc support for PPC64 > >> > Linux Little Endian? > >> > >> once the abi is clear (is long double ieee128?) the arch specific > >> parts of musl need to be ported for ARCH=powerpc64. > > > > IIRC one of the powerpc64 ABIs uses function descriptors rather than > > normal function pointers. If so that may affect a few details in the > > dynamic linker and may require some changes to non-arch-specific code, > > but since we have SH/FDPIC all the basic framework for function > > descriptors should be there already. > > PPC64LE Linux is little endian and does not use function descriptors. OK. I've been looking more and this is what's called the "ELFv2 ABI" for ppc64, I believe. Is it possible to use ELFv2 ABI with big endian targets? It looks like support is there on the toolchain side but I'm not sure if we would run into problems. The reason I'm asking is that there's probably also interest in older BE ppc64 systems and I think it makes more sense to use the same musl port/ABI for both endiannesses if at all possible rather than doing two separate ones. > > Also to clarify what you asked about long double ABI, if ieee128 > > (quad) is not used, the compiler needs to be built to use plain double > > (ieee64 double) for long double instead of using ibm double-double. > > GCC can use IEEE64 or IEEE128 for long double. OK. Then the choice of which to use depends mainly on whether there's current or future hardware that would do IEEE128 natively. If so we should probably choose an ABI that supports it even if in the short-term (or for the baseline ISA) it requires soft-float code to be linked; that's how AArch64 is doing it. But if native IEEE128 support is not available and not planned for future hardware, doing it as soft-float "just because" is probably not as good idea. > Is there any internal interest from the musl libc community for PPC64 > support that IBM could sponsor with a financial bounty on > bountysource.com? I would suspect so. Rich