From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9729 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: Tue, 22 Mar 2016 17:22:11 -0400 Message-ID: <20160322212211.GG21636@brightrain.aerifal.cx> References: <20160321173754.GC21636@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 1458681752 25135 80.91.229.3 (22 Mar 2016 21:22:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Mar 2016 21:22:32 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9742-gllmg-musl=m.gmane.org@lists.openwall.com Tue Mar 22 22:22:31 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 1aiTky-00049Q-AT for gllmg-musl@m.gmane.org; Tue, 22 Mar 2016 22:22:28 +0100 Original-Received: (qmail 24482 invoked by uid 550); 22 Mar 2016 21:22:25 -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 24459 invoked from network); 22 Mar 2016 21:22:24 -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:9729 Archived-At: 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/documentation/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 seem to be any info here specific to LL/SC, and the page 209 you cited is really sparse. If this is really the case then we probably need to consider whether some kind of awful runtime-switching mechanism is needed for baseline MIPS ISA levels, or whether users just have to consider R6 "incapable of running pre-R6 binaries". But in the latter case we might want to use a different dynamic linker name for R6. > >> arch/mips/atomic_arch.h | 8 ++++++++ > >> 1 file changed, 8 insertions(+) > >> > >> diff --git a/arch/mips/atomic_arch.h b/arch/mips/atomic_arch.h index > >> ce2823b..16b1542 100644 > >> --- a/arch/mips/atomic_arch.h > >> +++ b/arch/mips/atomic_arch.h > >> @@ -3,9 +3,13 @@ static inline int a_ll(volatile int *p) { > >> int v; > >> __asm__ __volatile__ ( > >> +#if __mips_isa_rev < 6 > >> ".set push ; .set mips2\n\t" > >> +#endif > >> "ll %0, %1" > >> +#if __mips_isa_rev < 6 > >> "\n\t.set pop" > >> +#endif > > > >I think just the .set mips2 could be inside #ifdef with the push/pop always > >used; that produces less #ifdef clutter. But first we need to figure out the > >above issues. > > We don't need push/pop if we are not doing mips2 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... Rich