From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14702 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] mips: add single-instruction math functions Date: Thu, 19 Sep 2019 15:10:18 -0400 Message-ID: <20190919191018.GH9017@brightrain.aerifal.cx> References: <20190911103224.504A15C44C@mx7.valuehost.ru> <20190913183123.GI9017@brightrain.aerifal.cx> <965098322.20190918201804@mobile-stream.com> <20190918200401.GD9017@brightrain.aerifal.cx> <1641023798.20190919155431@mobile-stream.com> <20190919131437.GF9017@brightrain.aerifal.cx> <14310266567.20190919212618@mobile-stream.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="191963"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: info@mobile-stream.com Original-X-From: musl-return-14718-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 19 21:10:38 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iB1p7-000nqa-Tp for gllmg-musl@m.gmane.org; Thu, 19 Sep 2019 21:10:37 +0200 Original-Received: (qmail 7661 invoked by uid 550); 19 Sep 2019 19:10:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7643 invoked from network); 19 Sep 2019 19:10:34 -0000 Content-Disposition: inline In-Reply-To: <14310266567.20190919212618@mobile-stream.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14702 Archived-At: On Thu, Sep 19, 2019 at 09:26:18PM +0300, info@mobile-stream.com wrote: > > >> 2) -mabs=2008 application will work correctly with -mabs=legacy musl > >> on a -mabs=2008 system. > > R> Are you sure? This seems to disagree with what you're saying below > > Yes, assuming they all were built with the same -mnan= option. > > The -mabs=2008 option has no ABI tag, it is just a compiler flag > that controls how many instructions are used for |x| and -x. > > I think there is some optimisation flag in gcc that does exactly the > same without declaring __mips_abs2008. > > Only -mnan=xxx consistency is enforced by the kernel basing on the > corresponding bits in the ELF header and FCSR. > > But yes, IIUC kernel assumes nan2008 binary is abs2008 too though > this has no deep (or whatever) meaning on cores with hard-wired > feature bits in FCSR. I guess I was assuming that if the two generally (always?) match in the hardware, you'd necessarily be using nan2008 when using abs2008. > R> musl supports multiple ecosystems in the same filesystem regardless of > R> whether a cpu does; that's the whole point of supporting even multiple > R> unrelated archs like mips and arm or x86 and riscv and why they all > R> have differing ldso names. For example you can be running the foreign > R> ISA via qemu-user with binfmt_misc or explicitly. > > OK. Though qemu-user has -L option for things like this. Indeed you can use -L in the qemu-user case, but there are plenty of other situations like shared rootfs across network or with qemu-system guests. In any case, ability for different archs and subarchs (ABIs) to coexist in the same filesystem regardless of any relationship or non-relationship between them has always been part of musl. > R> In that case, it seems like the kernel would refuse to load > R> -mabs=legacy binaries on nan2008 hardware, gratuitously due to > > No, no. The kernel only knows -mnan=xxx status for binary. > > All this mess is because architecture spec defines these features as > distinct, compilers have independent options for them (gcc even has > --with-nan= in ./configure but no --with-abs=), kernel code is > written like it can change FCSR bits etc. > > It reality these bits are always either both zero (non-existant on > <= R3) or both set in hardware and only NAN2008 FCSR bit has > reflection in the ELF header flags. In that case it seems like using abs2008 as you've proposed does not make the situation any worse than it might already be. Rich