[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190927115506.GO22009@port70.net>
Date: Fri, 27 Sep 2019 13:55:06 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: mips fp32/fpxx/fp64 issues, r6 sjlj broken
* 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.
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.
