From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16840 invoked from network); 4 Jun 2020 23:35:45 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 4 Jun 2020 23:35:45 -0000 Received: (qmail 11477 invoked by uid 550); 4 Jun 2020 23:35:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 11456 invoked from network); 4 Jun 2020 23:35:37 -0000 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 4 Jun 2020 18:35:16 -0500 From: Segher Boessenkool To: Daniel Kolesa Cc: musl@lists.openwall.com, Rich Felker , Michal =?iso-8859-1?Q?Such=E1nek?= , Joseph Myers , libc-alpha@sourceware.org, eery@paperfox.es, Will Springer , Palmer Dabbelt via binutils , via libc-dev , linuxppc-dev@lists.ozlabs.org Message-ID: <20200604233516.GM31009@gate.crashing.org> References: <20200602142337.GS25173@kitsune.suse.cz> <3aeb6dfe-ae23-42f9-ac23-16be6b54a850@www.fastmail.com> <20200604171232.GG31009@gate.crashing.org> <20200604171844.GO1079@brightrain.aerifal.cx> <20200604173312.GI31009@gate.crashing.org> <20200604211009.GK31009@gate.crashing.org> <60fa8bd7-2439-4403-a0eb-166a2fb49a4b@www.fastmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60fa8bd7-2439-4403-a0eb-166a2fb49a4b@www.fastmail.com> User-Agent: Mutt/1.4.2.3i Subject: Re: [musl] Re: ppc64le and 32-bit LE userland compatibility Hi! On Thu, Jun 04, 2020 at 11:43:53PM +0200, Daniel Kolesa wrote: > The thing is, I've yet to see in which way the ELFv2 ABI *actually* requires VSX - I don't think compiling for 970 introduces any actual differences. There will be omissions, yes - but then the more accurate thing would be to say that a subset of ELFv2 is used, rather than it being a different ABI per se. Two big things are that binaries that someone else made are supposed to work for you as well -- including binaries using VSX registers, or any instructions that require ISA 2.07 (or some older ISA after 970). This includes DSOs (shared libraries). So for a distribution this means that they will not use VSX *anywhere*, or only in very specialised things. That is a many-years setback, for people/situations where it could be used. > The ELFv2 document specifies things like passing of quadruple precision floats. Indeed, VSX is needed there, but that's not a concern if you *don't* use quadruple precision floats. As Joseph says, QP float is passed in the VRs, so that works just fine *if* you have AltiVec. If not, you probably should pass such values in the GPRs, or however a struct of 16 bytes is passed in whatever ABI you use (this is a much more general problem than just BE ELFv2 ;-) ) And then you have some kind of "partial soft float". Fun! (Or not...) > > If you always use -mcpu=970 (or similar), then not very much is > > different for you most likely -- except of course there is no promise > > to the user that they can use VSX and all instructions in ISA 2.07, > > which is a very useful promise to have normally. > > Yes, -mcpu=970 is used for default packages. *However*, it is possible that the user compiles their own packages with -mcpu=power9 or something similar, and then it'll be possible to utilize VSX and all, and it should still work with the existing userland. When speaking of ABI, what matters is... well, the binary interface, which is the same - so I believe this is still ELFv2. A subset is always compliant with the whole. The same calling convention will probably work, yes. An ABI is more than that though. > > Btw, if you use GCC, *please* send in testresults? :-) > > Yes, it's all gcc (we do have clang, but compiling repo packages with clang is generally frowned upon in the project, as we have vast majority of packages cross-compilable, and our cross-compiling infrastructure is gcc-centric, plus we enable certain things by default such as hardening flags that clang does not support). I'll try to remember next time I'm running tests. Thanks in advance! > I have a feeling that glibc would object to such port, since it means it would have to exist in parallel with a potential different ELFv2 port that does have a POWER8 minimal requirement; gcc would need a way to tell them apart, too (based on what would they be told apart? the simplest way would probably be something like, if --with-abi=elfv2 { if --with-cpu < power8 -> use glibc-novsx else use glibc-vsx } ...) The target name allows to make such distinctions: this could for example be powerpc64-*-linux-void (maybe I put the distinction in the wrong part of the name here? The glibc people will know better, and "void" is probably not a great name anyway). Segher