From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14741 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: mips fp32/fpxx/fp64 issues, r6 sjlj broken Date: Fri, 27 Sep 2019 13:55:06 +0200 Message-ID: <20190927115506.GO22009@port70.net> References: <20190926224520.GC9017@brightrain.aerifal.cx> <20190926232350.GD9017@brightrain.aerifal.cx> <20190927003821.GE9017@brightrain.aerifal.cx> <20190927111027.GN22009@port70.net> <20190927115254.GF9017@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="149824"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-14757-gllmg-musl=m.gmane.org@lists.openwall.com Fri Sep 27 13:55:22 2019 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.89) (envelope-from ) id 1iDoqH-000cng-Of for gllmg-musl@m.gmane.org; Fri, 27 Sep 2019 13:55:21 +0200 Original-Received: (qmail 21595 invoked by uid 550); 27 Sep 2019 11:55:19 -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 21577 invoked from network); 27 Sep 2019 11:55:18 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20190927115254.GF9017@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14741 Archived-At: * Rich Felker [2019-09-27 07:52:54 -0400]: > On Fri, Sep 27, 2019 at 01:10:28PM +0200, Szabolcs Nagy wrote: > > * Rich Felker [2019-09-26 20:38:21 -0400]: > > > On Thu, Sep 26, 2019 at 07:23:50PM -0400, Rich Felker wrote: > > > > On Thu, Sep 26, 2019 at 06:45:21PM -0400, Rich Felker wrote: > > > > > Also, mipsr6 (the new mips-family ISA that's not compatible with > > > > > previous mips) always uses the 64-bit register mode. We presently do > > > > > not have setjmp/longjmp code that works with this case at all > > > > > (existing code will wrongly save low 32-bits of 2 registers instead of > > > > > single whole double register); somehow nobody has noticed that this is > > > > > broken. Making this conditional on __mips_isa_rev >= 6 should not be > > > > > hard. > > > > > > > > Attached patch should work, but maybe isn't the best thing to do. I > > > > think using sdc1/ldc1 and just even indices like on r6 would also be > > > > valid for pre-r6 mips using fp32 or fpxx abi; with FR=0, it would > > > > save/restore the pair of 32-bit registers, and with FR=1, fp32 code > > > > could not be running anyway, and fpxx code should work fine. However, > > > > mips I lacks the ldc1/stc1 instructions, so at the very least we'd > > > > need to leave the old form in place for mips I. Or maybe use the s.d > > > > and l.d mnemonics that automatically assemble to the right choice > > > > based on the isa level... > > > > > > Two new versions of the patch. I think I prefer the last one. > > > > > > l.d and s.d expand to pairs of lwc1 and swc1 on mips1, and otherwise > > > expand to ldc1 and sdc1. ldc1 and sdc1 in turn behave just like pairs > > > of lwc1 and swc1 when FR=0, but additionally match the fpxx ABI when > > > FR=1. > > > > so a mips1 libc.so won't work on a system with FR=1? > > but a mips2 libc.so works with both FR=1 and FR=0? > > The ISA spec mandates that all mips r5 and earlier (this includes > mips1, mips2, mips32 up to r5) support FR=0, and the ABI for the > "mips" arch in musl is FR=0. So ability to work with FR=1 is not a > requirement. If built as fpxx (the default on all but old toolchains > or -march=mips1), the code could theoretically be linked with > fp64-model code and run in FR=1 mode, but musl does not support this; > doing it dynamically would require the dynamic linker manage the FR > mode, which is outside the scope of our ABIs model. > > > if mipsisa32r6 uses FR=1 and normal 32bit mips uses FR=0 > > then this sounds like an issue. > > mipsisa32r6 is a different incompatible ISA, so I don't see how it > poses an issue. Is there a particular concern you have that I'm > missing? ah right r6 uses different dynamic linker name so everything is fine then. either patch looks ok to me.