[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190919131437.GF9017@brightrain.aerifal.cx>
Date: Thu, 19 Sep 2019 09:14:37 -0400
From: Rich Felker <dalias@...c.org>
To: info@...ile-stream.com
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] mips: add single-instruction math functions
On Thu, Sep 19, 2019 at 03:54:31PM +0300, info@...ile-stream.com wrote:
> 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.
OK, this is really good to know. I tried to follow these discussions
when they first happened for the tooling and glibc, but got lost in it
all and was unclear on what the compatibility properties are and
whether they're different for nan2008 vs abs2008 (AIUI now they are).
> 2) -mabs=2008 application will work correctly with -mabs=legacy musl
> on a -mabs=2008 system.
Are you sure? This seems to disagree with what you're saying below
about the same ABI tagging being used for abs2008 and nan2008 and
kernel refusing to load mismatching binaries.
> 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.
Absolutely.
> 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.
musl supports multiple ecosystems in the same filesystem regardless of
whether a cpu does; that's the whole point of supporting even multiple
unrelated archs like mips and arm or x86 and riscv and why they all
have differing ldso names. For example you can be running the foreign
ISA via qemu-user with binfmt_misc or explicitly.
Now, musl doesn't really do anything special with signaling nans and
doesn't particularly consider them a supported feature, so in some
sense it probably does work anyway for them to mismatch. But if the
kernel refuses to load -mnan=legacy binaries on nan2008 hardware, that
undermines the above.
> 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).
In that case, it seems like the kernel would refuse to load
-mabs=legacy binaries on nan2008 hardware, gratuitously due to
conflating the two properties. :( Is that the case, and if so, is
there any way to avoid it?
> 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?
If the tooling is capable of treating them as the same ABI (which
implies considering signaling nan an unsupported feature and treating
all nans as the same), then it's not needed. But if it's enforced that
they're separate ABIs, they need separate ldsonames.
> (though all this nan2008 stuff is independent from the
> __mips_abs2008 fabs[f]() oneliners).
I think that sounds correct.
> 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).
OK.
> But do you essentially deny non-baseline musl without new ldsoname
> just because someone could misuse it on a baseline system?
No. It's the same ldsoname because binaries with or without dsp
features can use the same baseline (without dsp) libc.so/ldso.
> 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?
No. Both binaries using lzcnt and binaries not using lzcnt can share
the same ldso with the baseline 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.
Because the ABI is the same.
> 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.
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.
