From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9732 Path: news.gmane.org!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [PATCH] Fix atomic_arch.h for MIPS32 R6 Date: Wed, 23 Mar 2016 06:37:41 +0000 Message-ID: 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" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1458715082 17130 80.91.229.3 (23 Mar 2016 06:38:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2016 06:38:02 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-9745-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 23 07:38:02 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 1aicQb-0004ds-Tz for gllmg-musl@m.gmane.org; Wed, 23 Mar 2016 07:38:02 +0100 Original-Received: (qmail 7313 invoked by uid 550); 23 Mar 2016 06:37:58 -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 7286 invoked from network); 23 Mar 2016 06:37:57 -0000 Thread-Topic: [musl] [PATCH] Fix atomic_arch.h for MIPS32 R6 Thread-Index: AQHRg5hzySIsGLLUbES01dme3Dr6SZ9k53DggAC29oCAANgNAA== In-Reply-To: <20160322212211.GG21636@brightrain.aerifal.cx> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.93.60] Xref: news.gmane.org gmane.linux.lib.musl.general:9732 Archived-At: >-----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 c= ode). Is >this correct? If so that's really unfortunate. Unfortunately there does no= t R6 is not binary compatible with pre-R6. >seem to be any info here specific to LL/SC, and the page 209 you cited is = really >sparse. It is page 219 which talks about R6 and pre-R6 LL opcodes.=20 >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 level= s, >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= ... > The "m" constrain is still valid here, as the offset will be 0 in this case= . >Rich