From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9287 Path: news.gmane.org!not-for-mail From: David Edelsohn Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: musl libc for PPC64 Date: Mon, 8 Feb 2016 18:24:27 -0500 Message-ID: References: <20160208161758.GG9915@port70.net> <20160208165143.GA9349@brightrain.aerifal.cx> <20160208201802.GB9349@brightrain.aerifal.cx> <20160208225921.GD9349@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1454973890 21868 80.91.229.3 (8 Feb 2016 23:24:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Feb 2016 23:24:50 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-9300-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 09 00:24:41 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 1aSvAe-0008Hb-QN for gllmg-musl@m.gmane.org; Tue, 09 Feb 2016 00:24:41 +0100 Original-Received: (qmail 27855 invoked by uid 550); 8 Feb 2016 23:24:39 -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 27834 invoked from network); 8 Feb 2016 23:24:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PauZIpvmwdBZai3ymKEEYjqduhfGW8kEKCR8125RPLM=; b=FimcFONtqCeBPS1b5ldQMHdDr3SKX+hO2yfXuLSwrYmMLJKYSQT51q6XyJinTOUR2J a8DnzX+3lomkD0NTUU71GwWrjuiyonLj1UzPDVCn/wfqP0HCi1fK84wnybDalSnsDnc/ Qea7W/cHaQlVnKX50M/vvxoP0XPdnRMJ44ZSNDlO5JVOWm3TuEo9pL7GV14unnRUU54G pWn4zLcByWxwB0posrmvbkRB4jKWuszY2LXBAnHpINJ4E51sFMbdCePYgQZN+miLyedR 1PvLlfpqumg7iX3NU2sd3jPIGRTGj9MrawY4NANRR+JoI9/cUzK3hX+SHZ+N27qoTmzh pVRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PauZIpvmwdBZai3ymKEEYjqduhfGW8kEKCR8125RPLM=; b=VVIBqLbQz76cNE8cAhojjreucbsyPtV/0vrLyXp71G+UMiwKLZa/Wf0JrYMvm+zG3Y I9It/pMGXvP7Q9f4hhhHwhnGd+BERrKqBR2KcbSbLuCZ/mxncp9iG9Lt+DNQAOTPKAQh sJeboqpoDQtibN6tMRWVxXpnAEfKY7fVDP+txFZJBKg15r5nsLQAHNXq0bcBkRUiqPTE FnRLWALaliJsRgrZW4r06OyH0s0eTgItZfv/15L8NJdnzQ7H9Fa3wKYqH93JY2hXcmHf 805SHFcRHEtN7P0Qcp0KcmeygKG4fo3G/4WGpk0yo3EF7Ld0MRXRF1m2YygeO9qrAAmn AbeQ== X-Gm-Message-State: AG10YOT2fAq/LF7uudnoKSgwwzhMj0KdXjjIw4En8nRqlwtKz/Kt3vZyhHW1wQDNzEP11y/KxllAubMgE9nkBg== X-Received: by 10.25.141.129 with SMTP id p123mr10303023lfd.65.1454973867107; Mon, 08 Feb 2016 15:24:27 -0800 (PST) In-Reply-To: <20160208225921.GD9349@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9287 Archived-At: On Mon, Feb 8, 2016 at 5:59 PM, Rich Felker wrote: > On Mon, Feb 08, 2016 at 03:30:51PM -0500, David Edelsohn wrote: >> On Mon, Feb 8, 2016 at 3:18 PM, Rich Felker wrote: >> > 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. >> >> The future direction for Linux on PPC64 is little endian. I was >> trying to simplify things because of your comments about multiple >> ABIs. >> >> The original PPC64 ABI could (and has) operated in little endian mode, >> and the new PPC64 ELFv2 ABI could operate in big endian mode. But the >> entire PowerPC software ecosystem and all Linux distros are >> distributed with PPC64 big endian ABI using function descriptors and >> little endian ABI using ELFv2. > > Yes. For glibc and other systems with existing ecosystems, the old > ecosystem was based on the v1 ABI and was BE, and the new ecosystem is > based on the v2 ABI and is LE. But since musl doesn't have an existing > ppc64 ecosystem (and it's not ABI-compatible with glibc on ppc anyway > because of double-double and other issues) I think it makes sense to > use the v2 ABI for both LE and BE (if anyone even cares to do BE at > all). Does that make sense to you? You *can* use v2 ABI for BE, but there is no software to run. There is no software or ecosystem or operating system that runs v2 ABI BE. It's not a hardware limitation, but there is no environment for the alternate combination. > Of course either way, to begin with we can just start with the modern > LE ABI. > > BTW one thing I'm not clear on -- is there separate LE/BE hardware, or > does the same hardware just have a switchable mode? In the latter case > BE seems rather uninteresting to support at all, but maybe people want > to use it for routers or something? PowerPC processors support both little endian and big endian. The same systems can operate in either endian mode. > >> >> > 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. >> >> IBM has announced that the next generation of the processor will >> support native IEEE128 floating point in hardware. There will be >> software emulation for the current processors. Support is included in >> the forthcoming GCC 6. > > OK. Does the existing software emulation properly update the hardware > floating point status (exception flags) and use the rounding mode? I'm not sure what you mean. The software emulation assumes the hardware support is not present. It doesn't mirror back the state to the processor in 64 bit mode. But the emulation is fully IEEE128 compliant. > > Rich