[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190927144406.GG9017@brightrain.aerifal.cx>
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.
