From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11379 Path: news.gmane.org!.POSTED!not-for-mail From: Jaydeep Patil Newsgroups: gmane.linux.lib.musl.general Subject: RE: [MUSL] microMIPS32R2 O32 port Date: Thu, 1 Jun 2017 04:21:24 +0000 Message-ID: References: <20170421133300.GE17319@brightrain.aerifal.cx> <20170424134808.GQ17319@brightrain.aerifal.cx> <20170425165245.GW17319@brightrain.aerifal.cx> <20170528020057.GD1627@brightrain.aerifal.cx> <20170531131150.GH1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1496290904 27269 195.159.176.226 (1 Jun 2017 04:21:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Jun 2017 04:21:44 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-11392-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 01 06:21:39 2017 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.84_2) (envelope-from ) id 1dGHcB-0006rz-9O for gllmg-musl@m.gmane.org; Thu, 01 Jun 2017 06:21:39 +0200 Original-Received: (qmail 1637 invoked by uid 550); 1 Jun 2017 04:21:42 -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 1608 invoked from network); 1 Jun 2017 04:21:41 -0000 Thread-Topic: [musl] [MUSL] microMIPS32R2 O32 port Thread-Index: AdKt1iVvBw5zYQz8QaWQDACqF692CAA7R8oAACltEkAABLsbgAEB0oLgAARReIAAAig8gAACyxwAABlXkqD///FggP//iRXwgA1VrAD/+4O24IAJN4MA//61n8AAYglegP/+tFVQ/+YUh/D/tJARoP9mdSiA/sd34AD9jZjNEA== In-Reply-To: <20170531131150.GH1627@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.91.65] Xref: news.gmane.org gmane.linux.lib.musl.general:11379 Archived-At: Hi Rich, In the previous version of this patch (micromips32r2_v2), I had suggested t= o build the .s files as pure MIPS code (using ".set nomicromips" directive)= . However change in reloc.h is still required as it could be inlined in a mic= romips function. Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v2 = instead.=20 Thanks, Jaydeep >-----Original Message----- >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker >Sent: 31 May 2017 PM 06:42 >To: musl@lists.openwall.com >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port > >On Sat, May 27, 2017 at 10:00:57PM -0400, Rich Felker wrote: >> On Fri, May 26, 2017 at 03:46:49AM +0000, Jaydeep Patil wrote: >> > Hi Rich, >> > >> > Could you please find some time to review this? >> >> I'm trying to catch up now. Sorry I've been behind on this. > >OK. The only question I have is why the syscall_cp.s portion is needed at = this >stage. As long as all .s files are built as plain mips still (with support= for building >them as micromips to come in the future) it looks like this change belongs= as >part of that future patch. > >Rich > > >> > >-----Original Message----- >> > >From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] >> > >Sent: 11 May 2017 AM 08:56 >> > >To: musl@lists.openwall.com; Rich Felker >> > >Cc: Szabolcs Nagy; Andre McCurdy >> > >Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port >> > > >> > >Hi Rich, >> > > >> > >Could you please find some time to review >> > >https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 >branch? >> > > >> > >Thanks, >> > >Jaydeep >> > > >> > >>-----Original Message----- >> > >>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com] >> > >>Sent: 26 April 2017 PM 12:44 >> > >>To: Rich Felker >> > >>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >> > >>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port >> > >> >> > >>>-----Original Message----- >> > >>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich >> > >>>Felker >> > >>>Sent: 25 April 2017 PM 10:23 >> > >>>To: Jaydeep Patil >> > >>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy >> > >>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port >> > >>> >> > >>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote: >> > >>>> > But syscall_cp.s needs some care because saved instruction >> > >>>> >pointer values are compared against these labels. In micromips >> > >>>> >mode, do the labels evaluate with the +1 low bit offset? >> > >>>> >> > >>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. >> > >>>> However I don't see any issue with following comparison >> > >>>> >> > >>>> pc >=3D (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end >> > >>>> >> > >>>> The ISA bit will be set even for PC in the saved context. >> > >>> >> > >>>Agreed, I think it should work as expected. >> > >>> >> > >>>> >> >> diff --git a/src/thread/mips/syscall_cp.s >> > >>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e >> > >>>> >> >> 100644 >> > >>>> >> >> --- a/src/thread/mips/syscall_cp.s >> > >>>> >> >> +++ b/src/thread/mips/syscall_cp.s >> > >>>> >> >> @@ -1,5 +1,5 @@ >> > >>>> >> >> .set noreorder >> > >>>> >> >> - >> > >>>> >> >> +.set nomicromips >> > >>>> >> >> .global __cp_begin >> > >>>> >> >> .hidden __cp_begin >> > >>>> >> >> .type __cp_begin,@function >> > >>>> >> > >> > >>>> >> >I'm also unclear on the motivation of this one. Before (v1) >> > >>>> >> >you had a lot of changes to replace .s files with something >> > >>>> >> >micromips-compatible (removing branch delay slots); now >> > >>>> >> >(v2) those changes are not included. So are .s files even >> > >>>> >> >being built as micromips at all? If not, why is the above >> > >>>> >> >needed? If so, how do the files >> > >>>> >with delay slots work? >> > >>>> >> >> > >>>> >> Branch delay slots are removed (called as compact >> > >>>> >> instructions) in the newer MIPS/microMIPS cores (in >development). >> > >>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay >slot.. >> > >>>> >> Assembler takes care of converting a BRANCH + NOP to its >> > >>>> >> appropriate compact instruction (BEQ + NOP to BEQC). >> > >>>> >> With the v1 branch I was trying to create generic >> > >>>> >> hand-written assembly which can be used for newer cores with >> > >>>> >> the compact instructions. >> > >>>> >> However I realized that it would appropriate to create a new >> > >>>> >> arch instead of creating generic assembly. >> > >>>> >> Thus in v2 branch I modified only those functions which >> > >>>> >> would create issues when compiled with interlinking on. >> > >>>> > >> > >>>> >Based on the discussions so far, I don't think pure-micromips >> > >>>> >qualifies as a new arch. If it would be possible to take a >> > >>>> >program compiled as micromips- only, and run it with the >> > >>>> >libc.so/ldso built for plain mips on a machine that supports >> > >>>> >both forms of code, then it's not a separate arch, and as I >understand it this should be possible. >> > >>>> >> > >>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a >> > >>>> new >> > >arch. >> > >>>> >> > >>>> >Rich >> > >>>> >> > >>>> I will create v3 if you are OK with this approach. >> > >>> >> > >>>OK. Can you factor it as one patch that's the minimal needed to >> > >>>make the .c files (including ones that include the >> > >>>crt_arch.h/reloc.h asm >> > >>>code) build correctly in micromips mode, which should be quick to >> > >>>review/accept, and a second (if you want to do this phase now; if >> > >>>not you can leave it til later) that makes the .s files micromips- >compatible? >> > >> >> > >>Please refer to https://github.com/JaydeepIMG/musl- >> > >>1/tree/micromips32r2_v3 for changes (also attached as a patch). >> > >>I will push a separate patch to make .s file microMIPS-only compatib= le. >> > >> >> > >>>Rich >> > >> >> > >>Thanks, >> > >>Jaydeep