From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11624 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] powerpc64le: Add single instruction math functions Date: Thu, 29 Jun 2017 12:05:44 -0400 Message-ID: <20170629160544.GE1627@brightrain.aerifal.cx> References: <20170623193533.GO1627@brightrain.aerifal.cx> <594DB66E.7030009@adelielinux.org> <594DDEC6.8030200@adelielinux.org> <594EFC63.3000707@adelielinux.org> <20170625001024.GA1627@brightrain.aerifal.cx> 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 1498752360 14388 195.159.176.226 (29 Jun 2017 16:06:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Jun 2017 16:06:00 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11637-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 29 18:05:56 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 1dQbx4-0003SN-3m for gllmg-musl@m.gmane.org; Thu, 29 Jun 2017 18:05:54 +0200 Original-Received: (qmail 30670 invoked by uid 550); 29 Jun 2017 16:05:57 -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 30646 invoked from network); 29 Jun 2017 16:05:56 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11624 Archived-At: On Thu, Jun 29, 2017 at 09:49:34AM -0400, David Edelsohn wrote: > On Sat, Jun 24, 2017 at 8:10 PM, Rich Felker wrote: > > On Sat, Jun 24, 2017 at 06:57:23PM -0500, A. Wilcox wrote: > >> 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 don't see any reason GCC would introduce a problem here. It should > > always honor -march, and the default -march for the > > powerpc64-linux-musl (elfv2 of course) toolchain I just built seems to > > be POWER4 according to the predefined macros. > > > >> > 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 > > > > To clarify, my view is that it does not make sense to add a new port > > that differs only in ABI, unless it's an ABI variant that's actually > > necessary for reasonable support of some actual hardware (like > > softfloat, fdpic for nommu, etc.). That is not the case here. > > A colleague of mine reminded me that ELFv2 ABI specifies POWER8 as the > minimum hardware (not little-endian). This is a gratuitous requirement and has nothing to do with the meaning of ELFv2 we're using (and likewise not with the gcc --with-abi=elfv2). > The implementation of ELFv2 can > operate on earlier hardware, but binaries may not be forward > compatible because of VSX. Because of the calling convention of VSX > registers in ELFv2, the stack may be corrupted if an application built > without VSX support is linked with a library that does support VSX. > One cannot mix and match musl libc built for POWER4 or PPC970 and musl > libc built for POWER7. I don't think this is accurate. If it is then it's a serious bug we need to fix, and it should have been discussed at the time the port was added... Can you provide a citation for the usage of VSX registers in the calling convention, and how you think that affects the stack? Rich