Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 19 Sep 2019 15:54:31 +0300
From: info@...ile-stream.com
To: Rich Felker <dalias@...c.org>
CC: musl@...ts.openwall.com
Subject: Re: [PATCH] mips: add single-instruction math functions

R> It's not. The presence of a new instruction for non-arithmetic abs
R> would be a fine-grained ISA feature. An incompatible change in an
R> existing instruction is a *different ISA*, which needs a different
R> ldsoname per musl policy of always allowing different ISAs to coexist
R> in the same filesystem and have their own library ecosystems.

1) -mabs=legacy ("baseline") musl is safe on -mabs=2008 ("non-baseline") system cause it uses no explicit ABS.fmt in fabs[f]().
And since compiler does not generate trapping ABS.fmt/NEG.fmt unless specifically instructed there will be no implicit insns too. 
Even whatever explicit __mips_abs2008-protected code would not change (for good or for bad) anything here.

2) -mabs=2008 application will work correctly with -mabs=legacy musl on a -mabs=2008 system.

3) It is not musl's business if some -mabs=legacy application behaves unexpectedly on a -mabs=2008 system due to non-trapping ABS.fmt/NEG.fmt.

4) -mnan=legacy musl is probably not safe on a -mnan=2008 system but this is externally prevented by the kernel and there is *no* need for two ecosystems as CPU is *either* 2008 or legacy.

That is, this is *not* like o32 or n32 ABI on 64-bit MIPS (which can run these directly at the same time for different goals),
not a soft-float set of libraries on a hard-float system (which is usually just a subset with different argument passing convention),
not a hard-float binary on a soft-float system with kernel FPU emulation.

It is not even like r2 set of libraries on r6 (where kernel may want to emulate missing/redefined r2 instructions) -- *efficient* emulation of trapping ABS.fmt/NEG.fmt or 1985-style NaNs generation seems impossible on a 2008 system.

5) From the kernel pov (IIUC), nan2008 flag in the ELF header defines the abs2008 behaviour too (though these are distinct bits/flags per arch spec and in compilers).


I know glibc and uclibc have different ldso names for nan2008. I think it is because they have implemented it years ago when
1) the kernel had no nan2008 enforcement;
2) the mips r3 spec defined nan2008/abs2008 FCSR bits as possibly writable on a given CPU.

mips r5 spec has changed these bits to be strictly read-only and no r3 cores from IMG with writable nan2008/abs2008 bits exist (per spec at least).

So the feature bits are hard-wired, cross-binary and cross-system consistency is externally enforced, efficient emulation is barely possible.

Why bother with different ldsoname for nan2008 then?


(though all this nan2008 stuff is independent from the __mips_abs2008 fabs[f]() oneliners).


R> I'm guessing we've hit a situation where people have been building
R> binaries for an incompatible MIPS-family ISA reusing the same
R> ldsoname, which is a huge mess we probably need to figure out how to
R> deal with...

R> actually it probably doesn't matter even if it does since I can't
R> imagine the compiler generates dsp insns for anything in libc) you can

Sure it does, and for good. Indexed load/stores (gcc/clang), 64-bit additions with ADDWC/ADDSC (clang).

But do you essentially deny non-baseline musl without new ldsoname just because someone could misuse it on a baseline system?

If not, the -mabs=2008 ("non-baseline") musl on a -mabs=legacy ("baseline") system is irrelevant (though wrong of course).

If yes, do you consider x86 with LZCNT a different ISA?
It is perfectly possible to build musl with -mlzcnt ("non-baseline") and let it fail silently on non-ABM/BMIx system ("baseline").
Neither musl nor kernel prevents this yet nobody invents new ldsoname for this case.

It is probably possible to build soft-float ARMv6 musl with LDRD and let it crash on XScale v5TE system due to stricter alignment requirements.
Does musl prevent this with whatever ldsonames? I think not.
And if the kernel would reject such binary (dunno), why are you against external nan2008 enforcement then?

Finally, I believe it is possible to build mips32r2 binary with rotate instructions and let it fail silently and strangely on r1 system (rotate opcode reuses one of the shift opcodes) as kernel apparently ignores the corresponding flag in the ELF header.
This seems to be the only case of three you want to fix.





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.