Date: Fri, 27 Sep 2019 10:44:06 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: mips fp32/fpxx/fp64 issues, r6 sjlj broken On Fri, Sep 27, 2019 at 01:55:06PM +0200, Szabolcs Nagy wrote: > * Rich Felker <dalias@...c.org> [2019-09-27 07:52:54 -0400]: > > > On Fri, Sep 27, 2019 at 01:10:28PM +0200, Szabolcs Nagy wrote: > > > * Rich Felker <dalias@...c.org> [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. Thanks. Applying the latesst one since it should also solve the clang issue. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.