Re: [PATCH] mips: add single-instruction math functions

[Rich Felker <dalias@libc.org>]

On Thu, Sep 19, 2019 at 09:14:37AM -0400, Rich Felker wrote:
> On Thu, Sep 19, 2019 at 03:54:31PM +0300, info@mobile-stream.com wrote:
> > 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.
> 
> No, because the ABI is the same and you can run armv6 and armv5
> binaries using the same libc.so/ldso.
> 
> > 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.
> 
> This isn't about noisy or silent failure of binaries using new ISA
> features on old cpus. It's about the inability to use a
> baseline-supporting libc.so/ldso on a newer cpu with the changed ISA,
> for binaries built with the changed ISA.

The closest analogy to the mips situation might be arm where there are
separate branches of baseline ISA: armv4t, and the intersection of
armv7-a and armv7-m (called just armv7?). Here, there's currently no
way to make a single baseline ISA libc.so that can run on everything
just because armv4t lacks thumb2 and armv7-m lacks arm (the 32-bit arm
ISA). This is unfortunate but might be fixable if we ever get to the
point where building as thumb1 is supportable, but would break again
if we wanted to add plain armv4 (non-t) support (EABI doesn't specify
this but can be extended in a non-incompatble way).

I don't think the arm situation is an exact analogy since it does not
have completely disconnected components in the compatibility graph. It
just has 2 roots.

I bring this up because my last email was probably too long, and the
point here is not "rejecting abs2008/nan2008 without a new ldsoname"
but rather highlighting that there are issues that were never
discussed, and that might have already created a big mess in the wild,
and figuring out what if anything needs to be done about it. This
discussion should have happened a long time ago, and didn't, at least
not with musl.

Rich