From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11602 Path: news.gmane.org!.POSTED!not-for-mail From: "A. Wilcox" Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] powerpc64le: Add single instruction math functions Date: Sat, 24 Jun 2017 18:57:23 -0500 Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?= Message-ID: <594EFC63.3000707@adelielinux.org> References: <20170623193533.GO1627@brightrain.aerifal.cx> <594DB66E.7030009@adelielinux.org> <594DDEC6.8030200@adelielinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1498348678 7997 195.159.176.226 (24 Jun 2017 23:57:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 24 Jun 2017 23:57:58 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 To: musl@lists.openwall.com Original-X-From: musl-return-11615-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 25 01:57:54 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dOuw4-0001ir-GR for gllmg-musl@m.gmane.org; Sun, 25 Jun 2017 01:57:52 +0200 Original-Received: (qmail 17514 invoked by uid 550); 24 Jun 2017 23:57:55 -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 17493 invoked from network); 24 Jun 2017 23:57:54 -0000 X-Enigmail-Draft-Status: N1110 In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:11602 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/06/17 15:53, David Edelsohn wrote: > On Fri, Jun 23, 2017 at 11:38 PM, A. Wilcox > wrote: The ABIs are not endian-specific. > ELFv1 can operate as little endian (and did for a brief period as > a transition), ELFv2 can operate as big endian. PowerPC64 Linux > only will be 64 bit little endian going forward, although the > existing big endian, ELFv1 Linux distributions will continue to be > supported. There is no infrastructure or distribution into which > a PPC64BE ELFv2 libc can be installed. Is there a technical reason why PowerPC64 Linux will only be little-endian? Do the Power8 / Power9 chips not support BE mode for Linux officially? I have an IRC log where I was chatting with an IBM engineer and they said there is no reason P8/P9 can't run Linux in BE mode. The only reason to run LE mode is for better GPU support since most of the Radeons run their framebuffers in that mode (so you'd have much better performance, esp when using them for GPGPU). But that could have been then, and not now, since that conversation was almost a year ago. > A PPC64 big endian ELFv2 port is an interesting exercise, but does > not match or interact with any other Linux distributions or > toolchains. All of the PPC64 BE Linux ports are based on ELFv1 and > have no intention of changing. Except those based on musl? I mean, we at Adélie haven't /shipped/ anything PPC64 yet, but I have very good reasons for that (and will get to them later in this email). > I am not exactly certain what FreeBSD is planning. https://svnweb.freebsd.org/base?view=revision&revision=291668 FreeBSD supports either ABI in either endianness, but defaults to ELFv2 for both BE and LE with any compiler that supports it. >> Let us also not forget that LoPAPR[1] defines (at R1-2.7-1 in my >> copy, version 1.1 dated 24 March 2016) that Power Architecture >> platforms "must by default operate with Big-Endian addressing". > > I think that you're inferring too much into this statement. The > platform has to interoperate with big-endian addressing, especially > for firmware that assumes big endian, but that does not mean that > operating systems must support big endian user space applications. To me, the standard is completely clear that the operating system (this being the kernel, i.e. Linux itself, and base userland, i.e. musl) needs to support both to be compliant with the LoPAPR standard; at least §2.7, §4.2.3, §B.5.1. Of course, each distro can pick what it wants to support, what tool chain to use, and so on. But the base system needs to support both. >> Are you aware of any little-endian specific code in >> musl/powerpc64? I assume that libc-test would probably catch >> most of it when I am able to run it, but until then, it would be >> nice to know if there is anything I need to work on in the >> meantime. > > The PPC64 port of Musl does not assume little endian addressing, > but Musl currently only supports ELFv2. All of the toolchains and > operating systems that support ELFv2 are little endian. All of > the big endian toolchains and operating systems are designed for > ELFv1. There is no overlap. Except Adélie, Sabotage, and anyone who is creating their own environment without using a distribution. Or are you saying that GCC assumes LE with ELFv2? That is the primary reason I haven't shipped any PPC64 image yet. In addition to the usual badness of porting an entire distro worth of packages to a platform nobody has really used yet (had a similar time with musl on MIPS64 and 32-bit PowerPC), I'm a bit uneasy on the toolchain itself being able to understand what Rich has said. Since ELFv2 says that Power8 is the minimum ISA, gcc can do whatever it wants, and I'm not sure if -mcpu=power6 (specific lower ISA) or - -mcpu=powerpc64 (generic) will affect its code output when it sees - -mabi=elfv2. So I'm going to need to put any PPC64 image through a much more rigorous test than I did any other platform. > I added the macro tests for portability and completeness. > > The only ports of Musl that will function on existing, supported, > big-endian PowerPC systems are the 32 bit "powerpc" port and an > unimplemented PPC64 BE ELFv1 port. Except Rich specifically said that he did not want an ELFv1 port for 64-bit PowerPC when I asked him, so I don't think that's going to happen . Again, do you have a _technical_ reason that I cannot spend next weekend making a PPC64 BE image using musl + ELFv2 ABI? Or is this political / community in nature? I apologise if my words seem strong, but I do not take this lightly. We have a number of users clamouring for us to save their older PPC64 hardware from unmaintained AIX, unmaintained Debian, or in some cases ten-or-more year old fruity OSes. I obviously do not expect ABI compatibility with decades-old non-Linux Unixes. However, if there needs to be an ELFv1 port for a technical reason, I may have to investigate maintaining the port myself. Regards, - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZTvxTAAoJEMspy1GSK50UtNQP/3lceX5Aq9+uV15PkM54x6tr N0dlZOn5MGoPmyiudHy1Sj7olotwMTcGJXSJNNjGYibN72U6DcuxBCaorL1eGwjd n8dOUgua6vS2NurpfGLRtrBlOQpd+Hr/J3wP8OjMp+yUIvyZIUpvyBWqThTosaXm R5AP/NmjzWLJ5kc9Gv0hJv7Y3iT/5fCo3j5dx5FsZSqpE5U/fuzdEds9y6crHmaK Wkj6Vc6ejPYTz5LwjYFEY68Unz+du+gQ/DA67MFhG6feaaEUhv1ikqP1ThtjrFCn KOHH1tjRs3nTg+KkKR5LQbycW/39fmW9Mbk0kG5R1WQHvfqTRCff7b6HfiOpY1d9 ZFVxGyUZOSn7xSFHiY/gF5fb7hzh/r0TajDxtdN64Ap9jun/f+p+PPauWtFY5lPz N0DRV4+P8HeudcnZZbthhejQNL3Enq2rVxEvFJP1y13WHtsmDbLNFgFld2aIBlLC pqUjf8joh6cLMQn3+rbXAeZ4Rx1u0e7+eVhroH51EQhM24K4cqRWlwhXc48afoF8 qob0UZlT6DJ5LVSXiTPm+Ox3+4sr44490DhdJ+oNFhyfrztfg9VEi3lzFlkAPhQX YPaX6An80HxVKuEO4YJKQPkCThuJqbNG+2McgUBm+qL/AW4OByxO3WF/yXjyc3I0 JFtCuwWth5YlO8Re0WC1 =pI9q -----END PGP SIGNATURE-----