From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9738 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Fix atomic_arch.h for MIPS32 R6 Date: Wed, 23 Mar 2016 11:03:02 -0400 Message-ID: <20160323150302.GK21636@brightrain.aerifal.cx> References: <20160321173754.GC21636@brightrain.aerifal.cx> <20160322212211.GG21636@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1458745418 19419 80.91.229.3 (23 Mar 2016 15:03:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2016 15:03:38 +0000 (UTC) Cc: "musl@lists.openwall.com" To: Jaydeep Patil Original-X-From: musl-return-9751-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 23 16:03:33 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aikJp-0006K9-GR for gllmg-musl@m.gmane.org; Wed, 23 Mar 2016 16:03:33 +0100 Original-Received: (qmail 15505 invoked by uid 550); 23 Mar 2016 15:03:30 -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 15408 invoked from network); 23 Mar 2016 15:03:19 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9738 Archived-At: On Wed, Mar 23, 2016 at 06:37:41AM +0000, Jaydeep Patil wrote: > >-----Original Message----- > >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker > >Sent: 23 March 2016 AM 02:52 > >To: musl@lists.openwall.com > >Subject: Re: [musl] [PATCH] Fix atomic_arch.h for MIPS32 R6 > > > >On Tue, Mar 22, 2016 at 04:58:51AM +0000, Jaydeep Patil wrote: > >> >-----Original Message----- > >> >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of > >> >dalias@libc.org > >> >Sent: 21 March 2016 PM 11:08 > >> >To: musl@lists.openwall.com > >> >Subject: Re: [musl] [PATCH] Fix atomic_arch.h for MIPS32 R6 > >> > > >> >On Mon, Mar 21, 2016 at 06:03:47AM +0000, Jaydeep Patil wrote: > >> >> Hi Rich, > >> >> > >> >> The arch/mips/atomic_arch.h uses MIPS2 opcode for LL and SC > >> >> instructions. Opcodes of these instructions differ on MIPSR6. > >> > > >> >Does this mean MIPSR6 is an incompatible ISA that can't run normal > >> >MIPS binaries? If so that's a messy situation we need to find a way > >> >to deal with; if the difference is just LLSC though then perhaps the > >> >kernel's emulation handles it (albeit very slowly). > >> > > >> > > >> >It would be helpful if you could provide a link to the documentation > >> >of this issue (different opcodes). > >> > >> Refer to > >> https://imagination-technologies-cloudfront-assets.s3.amazonaws.com/do > >> cumentation/MD00086-2B-MIPS32BIS-AFP-06.04.pdf > >> (Page 209) for details. > > > >Page 454 contains the best info I could find, which seems to say that MIPS R6 > >is essentially a MIPS-incompatible ISA (it can't reliably execute pre-R6 code). Is > >this correct? If so that's really unfortunate. Unfortunately there does not > > R6 is not binary compatible with pre-R6. If R6 doesn't even try to be compatible with pre-R6 then I think we should treat it as a separate subarch and add "r6" in the dynamic linker name, either before or after the optional "el" component. Is there some general documentation of this incompatibility? How do GCC and binutils handle it? Are the ELF files flagged incompatible somehow? > >I was just saying it makes the code less cluttered to use them spuriously even > >though we don't need to: > > > > ".set push ; " > >#if __mips_isa_rev < 6 > > ".set mips2 ; " > >#endif > > "ll %0, %1 ; .set pop" > > > >or similar. > > > >It's also not clear to me whether the "m" constraint is valid anymore for the R6 > >ll/sc instructions since they take a 9-bit offset now instead of a 16-bit offset. > >The compiler could generate an address expression whose offset part does > >not fit in 9 bits. In that case we may need to #if the whole function (or at least > >the __asm__ statement) separately rather than just skipping the .set mips2.... > > > > The "m" constrain is still valid here, as the offset will be 0 in this case.. How can you assume the offset will be 0? It's the compiler's choice what to use. For instance, a_cas(&foo->bar, t, s) is likely to have an offset equal to offsetof(__typeof__(foo),bar). AFAIK this happens in practice with small offsets in mutex structures, etc. so the bug may be unlikely to be hit, but I think it's still an incorrect-constraint bug. Rich