From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9757 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: Mon, 28 Mar 2016 05:07:39 +0000 Message-ID: References: <20160321173754.GC21636@brightrain.aerifal.cx> <20160322212211.GG21636@brightrain.aerifal.cx> <20160323150302.GK21636@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 1459141679 28171 80.91.229.3 (28 Mar 2016 05:07:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Mar 2016 05:07:59 +0000 (UTC) Cc: "musl@lists.openwall.com" To: Rich Felker Original-X-From: musl-return-9770-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 28 07:07:59 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 1akPPC-0002e4-NV for gllmg-musl@m.gmane.org; Mon, 28 Mar 2016 07:07:58 +0200 Original-Received: (qmail 9526 invoked by uid 550); 28 Mar 2016 05:07:55 -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 9508 invoked from network); 28 Mar 2016 05:07:55 -0000 Thread-Topic: [musl] [PATCH] Fix atomic_arch.h for MIPS32 R6 Thread-Index: AQHRg5hzySIsGLLUbES01dme3Dr6SZ9k53DggAC29oCAANgNAIAAUFkAgAeMHPA= In-Reply-To: <20160323150302.GK21636@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:9757 Archived-At: >-----Original Message----- >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >Sent: 23 March 2016 PM 08:33 >To: Jaydeep Patil >Cc: musl@lists.openwall.com >Subject: Re: [musl] [PATCH] Fix atomic_arch.h for MIPS32 R6 > >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, ei= ther >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? There is no document which talks about this incompatibility particularly. The e_flags member of the ELF header has two new flags (E_MIPS_ARCH_32R6 an= d E_MIPS_ARCH_64R6) added for R6. We can choose to add "r6" in the dynamic linker's name. >> >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 instea= d 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 jus= t >skipping the .set mips2.... >> > >> >> The "m" constrain is still valid here, as the offset will be 0 in this c= ase.. > >How can you assume the offset will be 0? It's the compiler's choice what t= o >use. For instance, a_cas(&foo->bar, t, s) is likely to have an offset equa= l 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, bu= t I >think it's still an incorrect-constraint bug. Compiler generates appropriate LL/SC based on the offset.=20 Compiler adds the offset to the base register if it does not fit 9bits. >Rich